Split Mobile Payment System

ABSTRACT

Systems and methods for providing enhanced transaction security via use of a split mobile payment system which allows a Consumer to pay for a purchase using his mobile device without exposing Payment Account information to the merchant. The split mobile payment system may include a mobile payment application (MPA), running on a Consumer&#39;s mobile device, which can communicate with a Payment Platform and merchant&#39;s in-store Point of Sale Payment Application (PPA). A barcode can be used as one means for identifying a Consumer&#39;s Payment Account to the Payment Platform via the PPA. In the event of a PIN being required, the PIN may be entered by the Consumer via the mobile device rather than the merchant&#39;s PPA.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.13/469,864, filed May 11, 2012, which is a continuation-in-part of PCTPatent Application No. PCT/CA2012/000223 filed Mar. 12, 2012, and acontinuation-in-part of U.S. patent application Ser. No. 13/105,803filed May 11, 2011, and a continuation-in-part of U.S. patentapplication Ser. No. 13/397,215, filed Feb. 15, 2012, and acontinuation-in-part of U.S. patent application Ser. No. 13/397,297filed Feb. 15, 2012, which claims the benefits of U.S. ProvisionalPatent Application No. 61/485,075, filed May 11, 2011; the entirecontents of which are hereby incorporated by reference herein.

TECHNICAL FIELD

The present disclosure relates to a security-enhanced, mobile devicepayment processing system facilitating transfer of funds at a point ofsale using obfuscated payment account information to expedite paymentprocessing.

BACKGROUND

Mobile payment is an alternative payment method that allows consumers touse a mobile device (e.g. such as a smart phone) to purchase goods orservices, instead of using cash, cheque or credit card. Mobile paymentprocessing has been the “holy grail” of mobile commerce since the adventof the cell-phone.

However, the lack of efficient and easy-to-use mobile payment processingsolutions has heretofore relegated the mobile payment processing marketto predominantly the purchase of downloadable items such as ringtonesand music. Although many companies have tried, no one company has yetintroduced a comprehensive mobile payment processing technology that hasseen wide spread acceptance by either merchants or consumers.

In addition, consumers' concerns over the security of mobile paymentsystems have hindered the widespread adoption of such technology. Intraditional credit card or debit card based Point of Sale systems, whena consumer makes a purchase, the consumer's sensitive payment accountinformation is generally processed between a merchant's POS terminal anda Payment Platform (such as that of a credit card company, bank or otherfinancial institution). Further, the consumer is typically required toenter personal identification numbers (“PINs”), or other suchverification information such as passwords, on the merchant's POSterminal. While such technology is widely adopted, in the case of mobilepayment systems in particular, there remains a need for a mobile paymentsystem which can provide for enhanced security by reducing much of suchpayment processing functions from the merchant POS terminal.

In particular, providing one entity with some control in how theirpersonal financial information is provided to directly another entity(e.g. between consumer and merchant) involved in the funds transfer hasso far been elusive. This inability to involve more entity control ofthe funds transfer between entities while at the same time streamliningthe amount of time and information entities must share with each otherduring funds transfer has effectively relegated experience in onlineelectronic direct funds transfer to that of yesterday rather than thefuture. In particular, barcodes have been used in an effort to speed upthe customer shopping experiences by providing merchant terminalsinformation about the product when scanned through a checkout scanner,i.e. the price and brief description of the product that the barcode isattached/applied to. However, any use of barcodes outside of thecustomer shopping experience, other than as a look up service for aprice of a product on a product by product basis, is simply notavailable.

Further, mobile payment technologies have been contemplated using mobiledevices that utilize Radio-Frequency Identification (“RFID”) and/or NearField Communication (“NFC”) technologies as the means for identifying aConsumer/Consumer's account. However, with such devices, possessionequals ownership, meaning that a lost device can potentially be used bya fraudster to make unauthorized purchases. There is a need therefore toprovide for a mobile payment system having enhanced security features.

At the same time, developments in the field of mobile commerce are beingfacilitated by improved functionality and features available on mobiledevices, and by such functionality and features becoming morecommonplace on current mobile devices. For example, cell phones, smartphones and tablet computers nowadays are commonly integrated,multi-functional devices. In addition to their core, basicfunctionality, they will often have, or can be configured to have,web-enabled functionality, various other communication capabilities(e.g., e-mail, text, etc.), camera functions, scanning and graphicalimage handling functionalities and other capabilities. Graphicalinterfaces of desktop computers, including image processingcapabilities, have also become more advanced in their functionality andprovided features. However, to date, the direct funds transferexperience between entities (either in person or online) has notbenefited from these advanced functionality and provided features ofdesktop GUIs and mobile devices.

SUMMARY

Presently there is a need for a system and method to facilitate thetransfer of funds between entities such as a consumer and a merchantusing a code such as optical machine readable images to representconsumer account information that addresses at least one of theidentified problems in the current state of the art.

Currently, providing one entity with some control in how their personalfinancial information is provided to directly another entity involved inthe funds transfer has so far been elusive. This inability to involvemore entity control of the funds transfer between entities while at thesame time streamlining the amount of time and information entities mustshare with each other during funds transfer has effectively relegatedexperience in online electronic direct funds transfer to that ofyesterday rather than the future. Contrary to current systems there isprovided a system and method for a split transaction system forcoordinating processing of a purchase transaction between a merchant anda consumer over a communications network, the split transaction systemcomprising: a computer processor coupled to a memory, wherein thecomputer processor is programmed to coordinate processing of thepurchase transaction by: receiving the purchase transaction from themerchant including merchant identification information and consumeridentification information, such the consumer identification includesconsumer financial account information that is unusable to directlyaccess the corresponding financial account of the consumer; contactingthe consumer to notify the consumer of the received purchase transactionand to request confirmation information from the consumer; receiving theconfirmation information from the consumer and generating acorresponding funds transfer request using a funds amount associatedwith the merchant identification information and a financial accountnumber of the financial account of the consumer; and sending the fundstransfer request to an account processing system for subsequentsettlement of the funds amount with the financial account of theconsumer.

A first aspect provided is a split transaction system for coordinatingprocessing of a purchase transaction between a merchant and a consumerover a communications network, the split transaction system comprising:a computer processor coupled to a memory, wherein the computer processoris programmed to coordinate processing of the purchase transaction by:receiving the purchase transaction from the merchant including merchantidentification information and consumer identification information, suchthe consumer identification includes consumer financial accountinformation that is unusable to directly access the correspondingfinancial account of the consumer; contacting the consumer to notify theconsumer of the received purchase transaction and to requestconfirmation information from the consumer; receiving the confirmationinformation from the consumer and generating a corresponding fundstransfer request using a funds amount associated with the merchantidentification information and a financial account number of thefinancial account of the consumer; and sending the funds transferrequest to an account processing system for subsequent settlement of thefunds amount with the financial account of the consumer.

A second aspect provided is a method for coordinating processing of apurchase transaction between a merchant and a consumer over acommunications network, the split transaction method comprising:receiving the purchase transaction from the merchant including merchantidentification information and consumer identification information, suchthe consumer identification includes consumer financial accountinformation that is unusable to directly access the correspondingfinancial account of the consumer; contacting the consumer to notify theconsumer of the received purchase transaction and to requestconfirmation information from the consumer; receiving the confirmationinformation from the consumer and generating a corresponding fundstransfer request using a funds amount associated with the merchantidentification information and a financial account number of thefinancial account of the consumer; and sending the funds transferrequest to an account processing system for subsequent settlement of thefunds amount with the financial account of the consumer.

A third aspect provided is A non-transitory computer readable storagemedium with an executable program application stored thereon, theprogram application configured for coordinating processing of a purchasetransaction involving a consumer and a merchant, the program applicationconfigured as a client of a payment service platform accessible over acommunications network, wherein the program application instructs acomputer processor to perform the following steps of: providing consumeridentification information to the merchant, such the consumeridentification includes consumer financial account information that isunusable to directly access the corresponding financial account of theconsumer; receiving a notification from the payment service platform ofthe purchase transaction including merchant identification informationand a request to provide confirmation information from the consumerpertaining to the purchase transaction; sending the confirmationinformation to the payment service platform including confirmation of afunds amount associated with the merchant identification information;and receiving notification of subsequent settlement of the funds amountwith the financial account number pertaining to the financial account ofthe consumer.

The present disclosure is directed to a mobile payment system (andassociated method) which allows a Consumer to use his/her Mobile Deviceto facilitate/effectuate a financial transaction at a Point of Sale, andwhich has enhanced security features. It is contemplated that within thecontext of the present disclosure, “Mobile Device” can be used to referto any portable, wireless, web-enabled, electronic device, includingcell phone, electronic PDA, computer tablet, smart phone or a similardevice. The disclosed mobile payment system, sometimes referred toherein as a split mobile payment system (“split mobile payment system”),provides a solution that does not require the Consumer, when making sucha payment, to expose any confidential credit card, debit card orfinancial information to the merchant; nor does it need the Consumer toenter any credit card or debit card PIN numbers into a merchant's pointof sale application (PPA) Terminal.

The split mobile payment system makes use of a mobile paymentapplication (“MPA”) in the form of a software application which runs onthe Consumer's Mobile Device. The MPA may come preinstalled on theMobile Device and/or may be downloaded on to the Mobile Device. The MPAis configured to be able to communicate with the Payment Platform viathe Internet using the Mobile Device's web-enabled functionality. Themerchant's Point of Sale Payment Application (“PPA”—the softwareapplication running on the merchant's POS system or network, and used tofacilitate POS transactions) is also configured to be able tocommunicate with a Payment Platform either via the Internet or via adedicated connection. It is contemplated that such communications willinclude security features such as data encryption, as necessary.

The MPA communicates the Consumer's Payment Account Identifier (which isused to identify to the Payment Platform, the Consumer's Payment Accountthat the funds are to be transferred from to pay the merchant) to themerchant's PPA, which the PPA will pass on to the Payment Platform. Itis contemplated that several mechanisms can be used to communicate suchPayment Account Identifier to the PPA. In one embodiment, the use ofwhat shall be referred to herein as “Image Technology” contemplates thatthe Payment Account Identifier be in the form of a 1-D (linear) barcode,2-D barcode, hologram or the like (which for ease of reference willgenerally be referred to herein, as a barcode). In this embodiment, thebarcode is displayed on the screen display of the Consumer's MobileDevice, and presented to the merchant to be scanned (e.g., through a PPATerminal). In another embodiment, the use of what shall be referred toherein as “Transmitting Technology” contemplates that the PaymentAccount Identifier or information identifying the Consumer's PaymentAccount (“Payment Account Identifying Information”) will simply betransmitted from the Consumer's Mobile Device to the PPA using suchTransmitting Technology (i.e. NFC, Bluetooth, Infrared or other similarshortrange, communication technology). The merchant's PPA will besuitably equipped to receive such communication from the MPA/MobileDevice. It is contemplated that such communications will be suitablyencrypted.

Within the context of the present disclosure, the majority of thefunctionality of a traditional POS terminal is transferred to theConsumer's Mobile Device, resulting in the majority of the steps of apurchase transaction (particularly those involving relatively sensitiveinformation) taking place between the Consumer's Mobile Device and thePayment Platform (rather than between the merchant POS and a PaymentPlatform, as is typically the case in traditional retail credit cardtransactions).

Specifically:

The Consumer selects the type of payment transaction (e.g., credit card,debit card, bank debit, coupon or e-Wallet) using the Consumer's MobileDevice.

Debit card and/or credit card PIN authentication is performed betweenthe Consumer's Mobile Device and the Payment Platform, as opposed tobetween the PPA and the Payment Platform.

Transaction failure or insufficient funds notifications are sent to theConsumer's Mobile Device first, thereby allowing the Consumer to choosea different payment option and thus avoiding unnecessary potentialembarrassment.

In addition, the split mobile payment system provides several additionallayers of security (some of which can be optional) that operate tofurther reduce the chances of the Consumer's Payment Account Informationbeing compromised. Within the context of the disclosed system, a user isneeded to log in to the MPA (i.e., the MPA is password-protected) inorder to activate it on the Consumer's Mobile Device. In one embodiment,a user is also needed to log in to use the Mobile Device in the firstplace. In the context of the present disclosure, all relativelysensitive Payment Account Information of the Consumer is housed on thePayment Platform and not the Consumer's Mobile Device. Furthermore, allconfirmations of charges to or debits from the Consumer's PaymentAccount(s) require a confirmation by the Consumer from the Consumer'sMobile Device, as opposed to from the POS Terminal.

As an optional further security feature of the split mobile paymentsystem, a file photograph of the Consumer or Payment Account holder canbe sent to the in-store POS Payment Application (PPA) to request themerchant/cashier to verify the identity of the Consumer. Further, it iscontemplated that the disclosed system will provide for a confirmatione-mail (or other electronic communication) regarding the transaction tobe sent to the Mobile Device owner. All the foregoing of which canprevent, hamper or deter unauthorized use of the MPA or split mobilepayment system. Furthermore, in the eventuality of a credit card ordebit card PIN being needed, such PIN is entered by the Consumer via theConsumer's Mobile Device, rather than via the merchant's POS terminal,thus reducing the chances of the PIN being compromised.

The following outlines an exemplary embodiment of the process in action.

1. At the Point of Sale, the Consumer launches and logs in to the MPA onhis/her Mobile Device. This creates an open transaction on the PaymentPlatform.

2. The Payment Account Identifier, in the form of a barcode, ispresented on the screen display of the Mobile Device. This barcode isscanned by the merchant (e.g., using the PPA Terminal) to initiate thepayment transaction. The barcode is unique and serves to identify theConsumer's Payment Account(s) when the data contained in the barcode iscommunicated to a Payment Platform via the PPA. The Consumer's PaymentAccount may reside on a Payment Platform hosted by a financialinstitution, a credit issuing company, an E-wallet service provider, amoney transfer service provider, or the like. The information on thePayment Account Identifier/barcode and the purchase transactioninformation is sent by the PPA to the Payment Platform via the Internetor a dedicated connection.

3. In the event that the Consumer has sufficient funds in theirdesignated account, a request for confirmation of purchase is sent tothe Consumer's Mobile Device from the Payment Platform. The MPA presentsthe Consumer with options to accept or decline the transaction.

4. At this point the MPA may prompt the Consumer to enter his/her creditcard or debit card PIN number. If a PIN number is required, the Consumerenters his/her PIN number into a field presented by the MPA and that PINnumber along with the Consumer's confirmation of the transaction is sentvia the Internet or dedicated connection to the Payment Platform forauthentication.

5. If no PIN number IS required, the MPA just sends the confirmation tothe Payment Platform.

6. Upon accepting a confirmation from the Consumer, the Payment Platformprocesses the transaction and notifies both the merchant and theConsumer of the completion of the transaction.

In another embodiment, where use of a Transmitting Technology iscontemplated instead of Image Technology, step 2 above may be replacedby step 2b below:

2b. The Payment Account Identifier or the Consumer's Payment AccountIdentifying Information is transmitted from the MPA/Mobile Device usingthe Transmitting Technology to the PPA. The PPA sends this informationand the purchase transaction information to the Payment Platform via theInternet or a dedicated connection.

BRIEF DESCRIPTION OF THE DRAWINGS

Exemplary embodiments of the invention will now be described inconjunction with the following drawings, by way of example only, inwhich:

FIG. 1 is a simplified, schematic representation of a typical retailcredit card purchase;

FIG. 2 is a simplified, schematic representation of a typical merchantgift card purchase;

FIG. 3 is a block diagram of components of a split mobile paymentsystem;

FIG. 4 is a block diagram of a payment application of the system of FIG.3;

FIG. 5 shows example encoded and unencoded information for the system ofFIG. 3;

FIG. 6 is a block diagram of an example transaction service forcoordinating the funds transfer via the payment application of FIG. 4;

FIG. 7 is a block diagram of a computer device implementing the paymentapplication of FIG. 3;

FIG. 8 is a block diagram of a computer device implementing thetransaction service of FIG. 6; and

FIG. 9 is an example operation of the system of FIG. 3.

DESCRIPTION OF EMBODIMENTS

Glossary. For the purposes of this disclosure, the following terms havebeen ascribed the following meanings, with reference to FIG. 3:

Consumer 18—a Mobile Device 8 user; an individual making a purchase at aPoint of Sale terminal 12 of a merchant 16.

E-wallet—any electronic stored value system.

Point of Sale Terminal 12—any type of electronic payment terminal 12including, ATM machines, vending machines and standard in-store point ofsale terminals, such that the payment terminal implements a merchantpayment application/interface 14 that is in communication with a paymentservice platform 20.

Code data 4—is a lookup or index identifier (ID) that is received by thePoint of Sale Terminal 12 (e.g. via a merchant application 14) that canbe subsequently provided to and used by a payment service platform 20 toidentify sensitive payment account information 61 of the consumer 18, asmapped in a lookup table 63. For example, the lookup identifier providedas the code data 4 of “ABC123” could be received (via the merchantterminal 12) and used by the payment service platform 20 to lookup fromthe lookup table 63 the actual consumer credit card number (or otherfinancial account number). This actual financial account number wouldthen be provided to and used by financial institutions of the accountprocessing system 2 to effect transfer of funds from the consumerfinancial payment account 72 identified by the financial account numberretrieved from the lookup table 63. It is recognized that the code data4 can be included in a generated barcode 200 or can be provided to themerchant application 14 (via the consumer 18) as an unencoded code data4 (i.e. unencoded textual information).

Payment Service Platform 20—the computing infrastructure incommunication with, for example, banks, other financial institutions,E-wallet service providers or money transfer service provider network(represented as account processing system 2), that is used toauthenticate, for example, account holders, house account holderaccounts and to facilitate the electronic payment between account holderaccounts.

Payment Account 72—an financial account held by a Consumer 18 with afinancial institution, Ewallet provider or Credit Issuing Company(including gift certificates. gift cards and coupons), and the like(represented in account processing system 2), such as but not limited toa credit card account, a bank account, and/or a line of credit accountnumber, etc. It is recognized that access to the Payment Accountrequires access information from the consumer such as identityconfirmation data 3 including passwords and/or PIN.

Payment Account Information 61—Sensitive information pertaining to thePayment Account 72, including but not limited to account holder's name,name of financial institution, account login information, accountnumbers, account balances, passwords and PIN numbers for accessing theaccount. It is recognized that the payment account information 61 isused by an account processing system 2 to access and effect the actualtransfer of funds from the identified account 72 of the consumer 18 fromthe payment account information 61. It is also recognized that, asfurther described below, the payment account information 61 is withheldfrom the point of sale terminal 12 of the merchant 16 and is insteadcommunicated directly between the Payment Service Platform 20 and theconsumer 18 and communicated directly between the Payment ServicePlatform 20 and the account processing system 2.

POS or Point of Sale—the location where a purchase/sale transactiontakes place which originates a payment transaction 5 request (e.g. arequest from a merchant 16 to receive funds in exchange for a productbeing provided by the merchant 16 to the consumer 18).

Split Transaction Process—the transaction process that divides theinformation sent during a retail POS purchase between the Point of SaleTerminal 12, the Consumer's Mobile Device 8 and the Payment ServicePlatform 20 (via the payment interface 15).

Referring to FIG. 3, the present disclosure is directed to a mobilepayment system 10 and associated method implemented over a computernetwork(s) 11 such as the Internet and/or other public and private (e.g.VPN) inter- and extra-nets, wherein the system provides for enhancedtransaction security via use of a split mobile payment configuration.The split mobile payment configuration can comprise a softwareapplication or mobile payment application 13, which runs on theConsumer's mobile device 8 and which can communicate with the PaymentService Platform 20 and the merchant's in-store Point of Sale PaymentApplication 14. The split mobile payment system 10 allows the Consumer18 to pay for a purchase at a point of sale using their mobile device 8without exposing Payment Account information 61 to the merchant 16.Under the split mobile payment system 10, the Consumer's 18 sensitivePayment Account Information 61 can be processed between the Consumer'smobile device 8 and the Payment Service Platform 20 via networkconnection 1, while only a code 4 (e.g. a picture code or alphanumericcode) representing an identifier related to the Payment Accountinformation 61 is shared between the consumer 18 and the merchant 16. Itis recognized that the code 4 is recognized and used by the PaymentService Platform 20 to identify the consumer's actual stored PaymentAccount information 61 (see FIG. 4).

In the event of a credit card or debit card PIN being needed asconfirmation data 3 of the purchase transaction request 5 sent by themerchant 16 to the payment service platform 20, the PIN can be enteredby the Consumer 18 via the user interface of the Consumer's mobiledevice 8 rather than via the merchant's point of sale terminal 12, thusreducing the chances of the consumer's PIN being compromised as the PINinformation is not shared directly with the point of sale terminal 12.Further, an advantage with only providing the code 4 (only representingthe payment account information 61 of the consumer 18), by the consumer18 to the merchant 16, is that the merchant 16 does not have any directknowledge of the payment account number of the consumer 18 (as thisinformation is only known to the payment service platform 20 and/or therespective financial institution of the account processing system 2). Itis recognized that separate network 11 connections 0, 1 can be used totransmit the purchase transaction 5 (over network connection 0) betweenthe merchant device 12 and the payment service platform 20 and theconfirmation data 4 (over network connection 1) between the consumerdevice 8 and the payment service platform 20.

The computer network 11, often simply referred to as a network, can be acollection of hardware components and computers interconnected bycommunication channels (i.e. individual network connections 0, 1) thatallow sharing of resources and information between individual pairs ofdevices 6, 8, 12. Where at least one process in one device is able tosend/receive data to/from at least one process residing in a remotedevice, then the two devices are said to be in a network andcommunicating using their respective network connection of communicationchannel 0, 1. It is recognized that the network 11 can be comprised ofwired and/or wireless communication channels. It is recognized that theindividual devices 6, 8, 12 are individual nodes on the network 11, suchthat network connection 0 is defined as established between paireddevices 6, 12 as communication endpoints of the network connection 0,and network connection 1 is defined as established between paireddevices 6, 8 as communication endpoints of the network connection 0. Incommunication networks 11, a node is a connection point, either aredistribution point or a communication endpoint (some terminalequipment). The definition of a node depends on the network and protocollayer referred to. A physical network node is an active electronicdevice 6, 8, 12 that is attached to the network 11, and is capable ofsending, receiving, or forwarding information over their respectivecommunications channel (e.g. network connection 0 or network connection1). If the network 11 in question is the Internet or an intranet orother extranet, many physical network nodes are host computers (e.g.devices 6, 8, 12), also known as Internet nodes, identified by an IPaddress, and all hosts are physical network nodes. However, somedatalink layer devices such as switches, bridges and WLAN access pointsdo not have an IP host address (except sometimes for administrativepurposes), and are not considered as Internet nodes or hosts, but asphysical network nodes and LAN nodes.

In addition, the split mobile payment system 10 can provide additionallayers of security to that already present via the network 11architecture that inhibit or deter the Consumer's Payment Accountinformation 61 from being compromised. For example, one additional layeris where the Consumer 18 may be required to login in order to use themobile payment application 13. Optionally, a photograph of the Consumer18 may be sent to the merchant terminal 12 from the payment serviceplatform 20 for identity verification by the merchant 16, as part of theprocessing related to the purchase transaction 5 submitted to thepayment service platform 20 by the merchant 16. A confirmation e-mail orother electronic communication 3 can be sent to a designated e-mailaddress of the Consumer 18 (e.g. to the consumer device 8) from thepayment service platform 20, also as part of the processing related tothe purchase transaction 5 submitted to the payment service platform 20by the merchant 16.

In terms of data communication directly between the merchant device 12and the consumer device 8, this communication data 4 can be consideredoutside of the individual network communications 0, 1 in relation withthe payment service platform 20 over the network 11. A barcode 200 (seeFIG. 5) is one example of the code data 4, which is identifiable (e.g.is generated using an encoder that is compatible with a decoderimplemented by the payment service platform 20) by a payment interface15 of the payment service platform 20 in accessing the Consumer'sPayment Account (stored in the payment account information 61 in storageaccessible by the payment interface 15) to the account processing system2. In one embodiment, at the point of sale, the Consumer logs into theirpayment application 13. A barcode 200 containing the Consumer'sencrypted Payment Account Identifier 4 (i.e. code data 4) can bedisplayed on the screen of the mobile device 8. The barcode 200 can thenbe scanned by the Merchant device 12 using the merchant application 14.The scanned barcode information and all of the purchase information(i.e. total, Retailer ID etc.) can be sent as the purchase transaction 5by the merchant terminal 12 via the Internet 11 or a dedicatedconnection (e.g. via network connection 0) to the Payment ServicePlatform 20. The Payment Service Platform 20 can process the purchasetransaction 5 by using the code data 4 to identify the actual identityof the consumer 18 and their actual payment account information 61 andsend a “request for confirmation” request 3 (e.g. via network connection1) associated with the purchase transaction 5 to the payment application13 on the Consumer's mobile device 8. The Consumer 18 can then confirmor decline the request for confirmation as a confirmation response 3back to the Payment Service Platform 20 (e.g. via network connection 1),which can then interact with the account processing system 2 to effectthe transfer of funds indicated in the original purchase transaction 5between the accounts 70, 72 of the merchant 16 and the consumer 18.

The Consumer's 18 confirmation or declination of the purchasetransaction 5 can be sent through the Internet or dedicated connectionto the Payment Service Platform 20 via network connection 1, which cansend (e.g. via network connection 0) a purchase transaction response 5to the merchant terminal 12 (either before or after receivingconfirmation from the account processing system 2 of the specified fundstransfer between the accounts 70, 72). It is recognized that thetransfer of funds between the accounts 70, 72, as confirmed by theaccount processing system 2, can be a real-time executed funds transferand/or a promise to transfer, depending upon the effective speed atwhich the account processing system 2 can effect the actual fundstransfer). In any event, evidence of successful funds transfer in thepurchase transaction response 5 can be acceptable as either real-time(e.g. same day) or batch transfer (e.g. next day) of the funds betweenthe accounts 70, 72. A confirmation can also be sent to the paymentapplication 13 and an e-mail sent to the Consumer's designated e-mailaddress indicating successful funds transfer. The purchase transaction 5can then be considered closed or otherwise completed by the PaymentService Platform 20, the merchant application 14 and/or the paymentapplication 13, as desired.

In another embodiment, the code data 4 can be implemented as a shortcode service (i.e. unencoded textual information as compared to codedtextual information in the form of a barcode 200). The way this works isthat instead of scanning or otherwise supply the barcode 200 as the codedata 4, the consumer 18 provides a short code (e.g. a sequence ofcharacters including numeric characters and/or alpha characters) that isalso known to the Payment Service Platform 20 as the code data 4 used inidentifying the actual payment account information 61 stored andaccessible by the payment interface 15. Therefore, after providing thecode data 4 as a series of numeric characters and/or alpha characters tothe merchant application 14, the rest of the split purchase transaction5 process is exactly the same. One advantage in using the short code isthat it works in situations where generating or otherwisescanning/processing the barcode 200 is not feasible by the merchantapplication 14 and/or the payment application 13.

In another embodiment, the communication means for identifying theConsumer's Payment Account to the Payment Service Platform 20 via themerchant terminal 12 (i.e. via the merchant application 14) can involvethe transmission of the Consumer's Payment Account IdentifyingInformation 4 from the Mobile Device 8 (i.e. via the payment application13) to the merchant terminal 12 (i.e. via the merchant application 14)using NFC, Bluetooth, Infrared or other similar short-range,communication technology. In the case of a short code being used as thecode data 4, the transmission of this code data 4 information to themerchant may be something as simple as verbal transmission between themerchant 16 and consumer 18 and/or by simply reading of the code data 4off of the screen of the device 8 by the merchant 16—in the case wherethe code data 4 is displayed on the screen of the device 8 (e.g. viainteraction with the payment application 13 by the consumer 18). Anotherembodiment is where a speaker of the device 8 is used by the paymentapplication 13 to audibly communicate the code data 4 to the merchant16.

In contrast to the above described split mobile payment system 10, FIG.1 provides, for comparison purposes, a simplified illustration of atraditional retail purchase process using a credit card, according to anembodiment. A Consumer 100 wishing to make a purchase at a retailestablishment presents his/her credit card 105 to the merchant. Thecredit card 105 is swiped in the merchant's POS terminal 110. Whereappropriate, the Consumer inputs an account PIN into the POS terminal110 for verification purposes. The merchant POS terminal 110 initiates atransaction request with the credit card processor 120 or processinginstitution via the Internet or other facilitative network 115. Thecredit card processor 120 returns transaction confirmation details tothe merchant POS terminal 110 for display to the Consumer 100. It isrecognized that in this case all sensitive consumer account informationsuch as actual credit card number, personal name, as well as PINinformation is relayed through the POS terminal 110 (under control ofthe merchant 16) to the credit card processor 120 over the network 115.This credit card process is contrary to operation of the split mobilepayment system 10 whereby consumer sensitive information of PIN and/orcredit card numbers is transmitted directly between the paymentinterface 15 and the consumer device 8 over the network 11 (e.g. vianetwork connection 1) while the representative code data 4 and productpurchase information of the purchase transaction 5 is communicatedbetween the merchant device 12 and the payment interface 15, therebyproviding the advantage of restricting access by the merchant 16 to thepayment account information 61 (in this case PIN and credit card number)of the consumer 18.

FIG. 2 illustrates a traditional purchase process using a merchant giftcard, according to an embodiment. Consumer 100 wishing to make apurchase using an electronic stored value gift card 125 presents thegift card 125 to the merchant. The gift card 125 is swiped or scannedusing the merchant POS terminal or cash register 130. The balanceremaining on the gift card 125 is verified with the merchant's internalsystems 135 and the transaction is completed. It is recognized that inthis case all sensitive consumer account information such as actual giftcard number, personal name, as well as account balance information isrelayed through the POS terminal 130 (under control of the merchant 16)to the merchant's internal systems 135. This merchant gift card processis also contrary to operation of the split mobile payment system 10whereby consumer sensitive information of gift card balance and giftcard account number is transmitted directly between the paymentinterface 15 and the consumer device 8 over the network 11 (e.g. vianetwork connection 1) while the representative code data 4 and productpurchase information of the purchase transaction 5 is communicatedbetween the merchant device 12 and the payment interface 15, therebyproviding the advantage of restricting access by the merchant 16 to thepayment account information 61 (in this case gift card account numberand account balance) of the consumer 18.

Referring to FIG. 3, shown is the mobile payment system 10 forcompleting the purchase transaction 5 (e.g. an electronic transfer ofmoney from one account to another based on a purchase of a specifiedproduct by the merchant 16) between the merchant 16 (e.g. an entity suchas a product seller) and the consumer 18 (e.g. an entity such as aproduct buyer). The merchant 16 has a financial account 70 with theirfinancial institution (part of the account processing system 2) and theconsumer 18 has a financial account 72 with their financial institution(not shown), such that a payment service platform 20 coordinatessettlement of the purchase transaction 5 between the financial accounts70, 72 (as performed by a account processing system 2 such as but notlimited to one or more financial institutions or transaction exchangesoperating in conjunction or otherwise on behalf of the financialinstitutions at which the accounts 70, 72 are held). For example,purchase transaction 5 can be an exchange of money (e.g. $5) as a resultof goods or services changing hands between the merchant 16 and theconsumer 18 (e.g. buying a bicycle at a department store). An advantageof the mobile payment system 10, as further described below, is that themerchant 16 and the consumer 18 do not have to expose their personalfinancial information with one another, including personalidentifications numbers (PIN), financial institution account numbersand/or financial account passwords). The purchase transaction 5 caninvolves the use of an optical machine readable image (OMRI) 200 (alsoreferred to generically as barcode) as the code data 4 that containsencoded account information, as further described below (i.e. the codedata 4 is mapped to the stored payment account information 61 accessibleby the transaction interface 15 and therefore restricted from access bythe merchant 16 and/or the merchant application 14).

As described above, the code data 4 can also be represented as the shortcode, which is also used as an encoded version of the actual accountnumber to which the code data 4 is associated with (i.e. the code data 4is mapped to the stored payment account information 61 accessible by thetransaction interface 15 and therefore restricted from access by themerchant 16 and/or the merchant application 14).

Referring again to FIG. 3, the merchant 16 operates a computer device 12(having an installed payment application 13) and the consumer 18operates a computer device 8 (having an installed payment application13), such that computer devices 8, 12 can be in communication with oneanother and with a payment service platform 20 (having an installedtransaction interface 15) via a communications network 11. Thecommunications network 11 can be a one or more networks, for examplesuch as but not limited to: the Internet; an extranet; and/or anintranet. Further, the communications network 11 can be a wired orwireless network. It is also recognized that network 11 messages(between the various devices 6, 8, 12 and system 2) can be communicatedvia short range wireless communication protocols such as but not limitedto Bluetooth™, infrared (IR), radio frequency (RF), near fieldcommunication (NFC) and/or by long range communication protocols (e.g.HTTP, HTTPS, etc.), in view of the type of electronic communication(e.g. individual network connections 0, 1) used between any pair ofdevices 6, 8, 12 and system 2. For example, devices 8, 12 couldcommunicate with one another using short range Bluetooth™ communicationswhile devices 6, 8 and 6, 12 could communicate with one another usinglong range HTTPS based communications using individual networkconnections 0, 1.

It is recognized that network 11 communication messages facilitating theprocessing of the purchase transaction 5 are preferably between each ofthe applications 13, 14 and the transaction interface 15, rather thandirectly between the applications 13, 14 themselves (i.e. directlymeaning without interaction with the transaction interface 15).Therefore, in one embodiment, in the event that the applications 13, 14need (e.g. request) information from one another, these request (andresponse) network 11 messages would go through the transaction interface15 acting as an intermediary network interface between the applications13, 14 using the individual network connections 0, 1 as described above.The advantage with using the transaction interface 15 as theintermediary is that the sensitive payment account information 61 of theconsumer 18 is not provided to, transmitted by, or otherwise processedby the computer device 12 and/or merchant application 14 of the merchant16. However, it is recognized that network 11 messaging directly betweenthe applications 13, 14 can also be configured, for example for thepurpose of communicating the code data 4 while at the same timerestricting access by the merchant 16 to the payment account information61 of the consumer 18.

Further, the payment service platform 20 can communicate also via thecommunications network 11 with the account processing system 2 thatperforms the settlement (e.g. debit of funds specified in the purchasetransaction 5 from the account 72 and crediting of the funds in to theaccount 70) of the purchase transaction 5 between the financial accounts70, 72. It is recognized that the actual amount of debit and creditfunds actions performed by the account processing system 2 (i.e. thefunds amount specified in the purchase transaction 5 related to theproduct desired by the consumer 18) may not exactly match a funds amount203 (see FIG. 5) specified in the purchase transaction 5, due to appliedservice charges. For example, a payment request of $5 from the financialaccount 72 to the financial account 70 could result in an actual debitedamount of $5.02 (representing an included $0.02 service charge to themerchant 16) and/or an actual credited amount of $4.98 (representing anincluded $0.02 service charge to the consumer 18).

Therefore, it is anticipated that processing of the electronic purchasetransaction 5 by the split mobile payment system 10 can involve atransaction service charge being charged to the merchant 16 and/or theconsumer 18 in order to complete the purchase transaction 5 initiated bythe merchant 16. Purchase transaction 5 settlement can be defined aswhere the funds amount is transferred from the one account 70 to theother account 72, i.e. the credit and debit transactions of the fundsamount against the respective accounts 70, 72 are either performed (e.g.in real time) or promised to be performed (e.g. included in a batchtransaction to be performed later in the day or following business day).

Referring again to FIG. 3, the computer devices 8, 12 can each havetheir application 13, 14 that operates as a client of the paymentservice platform 20, such that at least the payment application 13 ofthe computer device 12 (of the merchant 16) is registered with thetransaction service 20. Registration details 17 (see FIG. 6) of themerchant 16 with the payment service platform 20 can include merchantdata such as but not limited to: identification ID 80 (e.g. MobileSubscriber Integrated Services Digital Network Number (MSISDN) as atelephone number, a unique identifier—different from the phonenumber—called the International Mobile Equipment Identity (IMEI), auniversally unique identifier (UUID) such as a MAC address or otherimplemented generation scheme for the UUID) of the computer device 12;merchant ID 82 that is or is otherwise associated (mapped, linked) tothe actual account number 70 of the merchant 16; and a unique encryptionkey 84 that is assigned to the merchant 16.

The consumer 18 can also be registered with the payment service platform20 and have registration details 17 including one or more consumer datasuch as but not limited to: identification ID 80 (e.g. Mobile SubscriberIntegrated Services Digital Network Number (MSISDN) as a telephonenumber, a unique identifier—different from the phone number—called theInternational Mobile Equipment Identity (IMEI), a universally uniqueidentifier (UUID) such as a MAC address or other implemented generationscheme for the UUID) of the computer device 8; consumer ID 82 that is oris otherwise associated (mapped, linked) to the actual account number 72of the consumer 18; and a unique encryption key 84 that is assigned tothe consumer 18.

It is recognized that in view of the above, any of the registrationdetails 17 (of the merchant 16 and/or the consumer 18) can be includedin any information data associated with the purchase transaction 5 thatis received by the payment service platform 20. Further, it isrecognized that any of the registration details 17 (of the merchant 16and/or the consumer 18) can be incorporated in to the OMRI 200 (thatincludes the code data 4 as encoded account information) used tofacilitate the purchase transaction 5, as further described below.

The payment service platform 20 is implemented on the computer device 6(e.g. a web server) and communicates over the communications network 11with the computer devices 8, 12 via a hosted transaction interface 15.The transaction interface 15 of the payment service platform 20 can be aweb site accessible over the communications network 11 by the computerdevices 8, 12 using respective web browsers operating on the computerdevices 8, 12, such that the transaction interface 15 is in respectivecommunication with the applications 13, 14 of the client devices 8, 12.Accordingly, the transaction interface 15, computer device 12 andcomputer device 8 can interact (e.g. via network 11 messages) togetherto initiate and complete the purchase transaction 5, for example basedon products offered and sold by the merchant 16 to the consumer 18, suchthat the code data 4 (e.g. OMRI 200—see FIG. 5) is generated (orotherwise provided) and included as part of the initiation and/orprocessing of the purchase transaction 5 in conjunction with the orderinterface 15.

Code Data 4

As described above, the code data 4 can be represented as the shortcode, which is also used as an encoded version of the actual accountnumber to which the code data 4 is associated with (i.e. the code data 4is mapped to the stored payment account information 61 accessible by thetransaction interface 15 and therefore restricted from access by themerchant 16 and/or the merchant application 14). In this embodiment, thecode data 4 is implemented as a short code service, such that instead ofscanning or otherwise supplying the code data 4 as the barcode 200, theconsumer 18 provides a short code (e.g. a sequence of charactersincluding numeric characters and/or alpha characters) that is also knownto the Payment Service Platform 20 as the code data 4 used inidentifying the actual payment account information 61 stored andaccessible by the payment interface 15. Therefore, after providing thecode data 4 as a series of numeric characters and/or alpha characters tothe merchant application 14, the rest of the split purchase transaction5 process is similar to using the barcode 200 also an encodedrepresentation of the actual payment account information 61 that isrestricted from access by the merchant 16. One advantage in using theshort code is that it works in situations where generating or otherwisescanning/processing the barcode 200 (also referred to as ORMI) is notfeasible by the merchant application 14 and/or the payment application13. In this manner, the code data 4 is received by the merchantapplication 14 for subsequent incorporation into the data of thepurchase transaction 5 communicated (e.g. via network connection 0)directly with the payment service platform 20 (e.g. via the transactioninterface 15). In this manner, direct access to the payment accountinformation 61 (e.g. actual financial account 72 number and/or accountaccess password such as PIN of the consumer 18) by the merchant isrestricted, as the code data 4 is used by the payment service platform20 as a lookup identifier for accessing the actual financial accountnumber information 61 mapped or otherwise associated with the code data4 stored or otherwise accessible by the transaction interface 15 in alookup table or index 63 (see FIG. 6).

Referring to FIG. 5, the OMRI 200 (i.e. an optical machine-readablerepresentation of data) provides the code data 4 as symbologyinformation 204 in encoded form based on a coding scheme 209. Oneexample of the OMRI 200 is a barcode, such that the coding scheme 209 isa barcode coding scheme for use in encoding and decoding of thesymbology information 204 of the barcode. Another example of the OMRI200 is a dataglyph, such that the coding scheme 209 is a dataglyphcoding scheme for use in encoding and decoding of the symbologyinformation 204 of the dataglyph.

The OMRI 200 is used by the system 10 to represent and facilitateprocessing of the purchase transaction 5 by representing textualinformation 201 (e.g. consumer 18 identification or account 70, 72information, a transaction number identifying the purchase transaction5, product descriptions and/or transfer terms including password or PINrelated information corresponding to the account 70 and/or the account72, etc.) that is encoded as symbology information 204 in the OMRI 200.It is recognized that the purchase transaction 5 can be initiated by themerchant 16 representing a seller of a product (e.g. a good or serviceprovided by the seller to the buyer) or could be initiated by theconsumer 18 representing the buyer of the product in the case where thebuyer makes an unsolicited offer/bid for an available product (of apotential seller).

As discussed below, the computer device 8 does not necessarily have tocommunicate with the computer device 12 over the communications network11, in order to provide the OMRI 200. Instead, the consumer 18 canrecord or otherwise generate an image of the OMRI 200 by using an imagerof the computer device 8 (e.g. a camera 118 enabled mobile device—seeFIG. 7), for subsequent display by the payment application 13 andcapture by the computer device 12. In this example, the user interface104 (see FIG. 7) of the computer device 8 can display the OMRI 200within range of the camera 118 of the computer device 12 for subsequentreceipt as a recorded image. In this manner, the code data 4 encoded inthe OMRI 200 is received by the merchant application 14 for subsequentincorporation into the data of the purchase transaction 5 communicated(e.g. via network connection 0) directly with the payment serviceplatform 20 (e.g. via the transaction interface 15). In this manner,direct access to the payment account information 61 (e.g. actualfinancial account 72 number and/or account access password such as PINof the consumer 18) by the merchant is restricted, as the code data 4 isused by the payment service platform 20 as an lookup identifier foraccessing the actual financial account number information 61 mapped orotherwise associated with the code data 4 stored or otherwise accessibleby the transaction interface 15 in a lookup table or index 63 (see FIG.6).

Definition of Products

In economics, economic output is divided into goods and services. Whenan economic activity yields a valuable or useful thing, it can be knownas production output of the totality of products (e.g. goods orservices) in an economy that is made available for use by someone else.Products as goods can range from a simple safety pin, food, clothing,computer components to complex machinery and electronic or physicalmedia (physical or electronic versions of music, print media, etc.).Products as services are the performance of any duties or work foranother (e.g. helpful or professional activity) and can be used todefine intangible specialized economic activities such as but notlimited to: providing access to specific information; web services;transport; banking; legal advice; accounting advice; managementconsultant advice; and medical services. The entity providing theproducts can be a businessperson or individual engaged inwholesale/retail trade, an organization, an administration, and/or abusiness that sells, administers, maintains, charges for or otherwisemakes available product(s) that are desirable by their customer.Accordingly, the entity providing (e.g. selling) the product can be oneperson, or an association of persons, for the purpose of carrying onsome enterprise or business; a corporation; a firm; etc.

Further, it is recognized that the products can be related to companyactivities not related to specific product(s), for example customerservice, community activities, donations, and/or sponsorships. Thesegeneral activities of the entity providing the product are alsoconsidered as part of the definition of products. As discussed above,the exchanged funds can be as a result of payment of a debt by a debtorto a creditor, hence in this case the product is a loan of funds betweenthe debtor and creditor. A further related example is where theexchanged funds can be as a result of loaning a sum of money (i.e.creating a debt) between the debtor and the creditor. Also as discussedabove, the debtor and/or creditors can be entities embodied asindividuals (e.g. a person), companies (e.g. banks), etc. Further, it isrecognized that the products can include restaurant meals (and/orservice), such that the purchase transaction 5 represents a meal billand the products are individual food and/or beverage items. It is alsorecognized that the products can be groceries or other retail itemsbeing paid for in person by the consumer 18 at a merchant retailestablishment, for example.

As further discussed, the funds amount 203 of the purchase transaction 5is entered via the payment application 14 of the computer device 12. Thepayment application 13 provides the merchant 16 with the ability toselect and/or specify the funds amount 203 and can also include the OMRI200 (see FIG. 5) that contains encoded code data 4 information (in thesymbology information 204) representing summary information (e.g.optional product listing/description, purchase identificationinformation, consumer ID, selected consumer account ID or type, etc.).It is also recognized that the purchase transaction 5 can represent aplurality of products, e.g. representing funds amount 203 data for twoor more products.

In any event, it is recognized that the OMRI 200 can be received by thepayment application 13 of the computer device 12 to contain code data 4(as well as any optional data such as but not limited to the fundsamount data 203, consumer data 208, merchant data 211 and/or purchasedata 210) of the purchase transaction 5, including transaction data usedby the payment service platform 20 in order to coordinate the settlementof the purchase transaction 5 via the account processing system 2 (i.e.transferring funds from one specified account 70, 72 to anotherspecified account 70, 72). It should be noted that the actual generationof the OMRI 200 can be alternatively performed by the payment serviceplatform 20 on behalf of the payment application 13 upon request, asfurther described below.

OMRI 200

Referring to FIG. 5, as used herein, the term OMRI 200 (e.g. barcode,dataglyph, etc.) refers to an optical machine-readable representation ofencoded information or data, presented as an ordered pattern of symbols(i.e. symbology information 204). For example, barcodes can encodeinformation in the widths and the spacing of parallel lines, and may bereferred to as linear or 1D (1 dimensional) symbologies. Barcodes canalso encode information in patterns of squares, dots, hexagons and othergeometric shapes or symbols within images termed 2D (2 dimensional)matrix codes or symbologies. Typically, although 2D systems use symbolsother than bars, they are generally referred to as barcodes as well.Accordingly, barcode images discussed herein for use with a barcodeencoder or decoder can refer to either 1D or 2D barcodes. Withconventional monochromatic barcodes, features are typically printed inblack on a white background, thereby forming a pattern that is used toform the machine-readable representation of the code data 4 (andoptionally any other information useful in the purchase transaction 5).With color barcodes, the pattern can include any number of colors(typically also including black and white) distinguishable from oneanother during the barcode decoding process.

The OMRI 200 is generated to include symbology information 204representing code data 4. As discussed further below, the OMRI 200 canbe electronically displayed (e.g. on a computer display), can beprovided as graphic content (e.g. an image file such as but not limitedto a GIF or JPEG) in a network message and/or can be provided in printedform (e.g. presented on a physical medium such as paper or plastic—forexample presented on a label). As discussed, interaction between theOMRI 200 and the merchant 16 (see FIG. 3) can include merchant 16actions such as but not limited to: selection (e.g. via mouse or otherpointer) on a user interface 104 (see FIG. 7) of the computer device 8displaying the OMRI 200; receiving an image file containing the OMRI200; and/or recording/capturing the image of the OMRI 200 using animager 118 (e.g. camera) of the computer device 12 (e.g. mobile device),such that the OMRI 200 is displayed on physical media and/or electronicmedia (i.e. an electronic display adjacent to the merchant device 12 andin-range of the imager 118). Example environments of the described imagecapture process would be where the OMRI 200 is displayed on the computerdevice 8 of the consumer 18.

In terms of the symbology information 204 of the OMRI 200, the symbologyinformation 204 includes a plurality of symbols (i.e. graphicalelements) that, as a collection of symbols or patterns (e.g. anorganized collection of symbols forms a legend, or key), representsencoded funds information that is distinct from the actual unencodedtextual information itself. For example, a graphical element (of thesymbology 204) of a black line of a specific width represents a textualelement (of the textual information) as the number six, while adifferent width represents a different textual element (of the textualinformation) such as the number two. It is recognized that graphicalelements can be pictures (e.g. images) of text elements and/or ofnon-text elements. For example, the graphical element “6” (e.g. encodedor symbology information 204) in the coding scheme 209 could be mappedto a code data “1234” (e.g. unencoded information). In another example,the graphical element “(*)” (e.g. encoded or symbology information 204)in the coding scheme 209 could be mapped to a code data “1234” (e.g.unencoded information).

The purpose of the symbology information 204 is to communicate encodedinformation as readable (e.g. decodable) by an image decoder 119 orotherwise encodable by an image encoder 121. The decoder 119 could bepresent on the computer device 8 and/or on the payment service platform20, as further described below. It is recognized that mapping (i.e.processing performed by the decoder 119 or encoder 121) between thesymbology information 204 and the textual information is what enablesthe OMRI 200 to be generated and interpreted. A specification of thesymbology information 204 can include the encoding of the singledigits/characters of the textual code data 4 as well as the start andstop markers into individual symbols (e.g. bars) and space between thesymbols of the symbol collection/pattern, the size of a quiet zonerequired to be before and after the OMRI 200, as well as a computationof a checksum incorporated into the OMRI 200 for error checking purposesas is known in the art.

It is recognized that the OMRI 200 may not contain descriptive data,rather the OMRI 200 can be used as reference codes (e.g. decodedinformation) that a computer uses to look up an associated record thatcontains the descriptive textual code data, as well as any otherrelevant information associated with the textual code data encoded inthe OMRI 200. For example, the matching item record of the symbologyinformation 204 can contain an optional description of the product,consumer and/or merchant name, funds amount, merchant or consumerfinancial account information lookup identifiers or designations, etc.,including any of the product data 206, merchant data 208, consumer data211 and/or purchase data 210 as further described below. However, someOMRI 200 can contain, besides reference ID, additional or supplementalinformation such as product name or manufacturer, for example, and some2D OMRI 200 may contain even more information as they can be moreinformationally dense due the greater variation potential of the printedpatterns over those of 1D OMRI 200.

In terms of different barcode type, linear symbologies (e.g. UPCbarcodes as an example symbology format of the barcode) can beclassified mainly by two properties, continuous vs. discrete andtwo-width vs. many-width. In continuous vs. discrete, characters (i.e.representing the invoice data content) in continuous symbologies usuallyabut, with one character ending with a space and the next beginning witha bar (e.g. light-dark patterns), or vice versa. Characters (i.e.representing the invoice data content) in discrete symbologies begin andend with bars and any intercharacter space is ignored as long as it isnot wide enough to look like the code ends. In two-width vs. many-width,bars and spaces in two-width symbologies are wide or narrow, and theexact width of a wide bar has no significance as long as the symbologyrequirements for wide bars are adhered to (usually two to three timeswider than a narrow bar). Bars and spaces in many-width symbologies areall multiples of a basic width called the module, wherein most suchcodes use four widths of 1, 2, 3 and 4 modules. Some linear symbologiesuse interleaving, such that the first character (i.e. representing theinvoice data content) is encoded using black bars of varying width. Thesecond character (i.e. representing the invoice data content) is thenencoded, by varying the width of the white spaces between these bars.Thus characters (i.e. representing the invoice data content) are encodedin pairs over the same section of the barcode. Stacked symbologiesrepeat a given linear symbology vertically.

In terms of multidimensional symbologies (e.g. 2D, 3D, etc.), the mostcommon among the many 2D symbologies are matrix codes, which featuresquare or dot-shaped modules (i.e. representing the invoice datacontent) arranged on a grid pattern. 2-D symbologies also come incircular and other patterns and may employ steganography, thereby hidingmodules within an image (for example, using DataGlyphs). Aztec Code isanother type of 2D barcode.

Quick Response Codes (QRC) are another a type of matrix barcode (ortwo-dimensional code) providing faster readability and larger storagecapacity compared to traditional UPC barcodes. The QR code (as anexample symbology format of the barcode) consists of black modulesarranged in a square pattern on a white background. The informationencoded can be made up of four standardized kinds (“modes”) of encodeddata (e.g. numeric, alphanumeric, byte/binary, and/or Kanji), or bysupported extensions virtually any kind of data.

It is also recognized that the symbology information 204 of the OMRI 200can include custom graphical elements (as codified in the coding scheme209) involving combinations of one or more graphical elements used torepresent a textual element, e.g. a corporate logo is used as acollection of graphical elements (e.g. circle, square, and company name)that is mapped (e.g. decoded) by the coding scheme 209 to represent atextual element (e.g. a URL to a webpage of the company website).Alternatively, the textual element can be mapped (e.g. encoded) by thecoding scheme 209 to represent the collection of graphical elements. Inthis example, the graphical element of a company name (the symbologyinformation 204) is decoded by the coding scheme 209 to represent thetext of the URL (the textual information). One example of barcodescontaining custom graphical elements is Microsoft™ Tag barcodes.

Microsoft™ Tags as an OMRI 200 are another type of barcode, e.g. 2Dbarcodes, which offer more flexibility than traditional barcode formatsboth in the barcode design and the content behind it. Because MicrosoftTag barcodes can be linked to data stored on a server, you can deliver amore robust online experience—including entire mobile sites—and updatethe content any time without having to change the Microsoft Tag. So, ifyou link a Microsoft Tag on your business card to your résumé, it willstill be valid after you get that big promotion. Microsoft Tags can beblack-and-white or full-color, including custom images (e.g., a companylogo). Therefore, the Microsoft Tag can have encoded data in thesymbology information 204 of the Tag that includes a link (e.g. URL) orother hyperlink that references a location in memory (e.g. in adatabase) and/or a network address where data content isavailable/accessible via the encoded link. In other words, a Tag encoderwould use a Tag coding scheme 209 to encode the textual link informationinto corresponding symbology information 204, e.g. the hyperlink to awebsite (the textual link information associated with or otherwise usedto retrieve the code data 4) would be represented as one or moregraphical elements such as a company logo or even graphical elements(the symbology information 204) picturing the product itself.

It is also recognized that the symbology information 204 of the OMRI 200can be encrypted (e.g. using a DES algorithm). In terms of the format ofthe symbology information 204, codewords embedded/encoded in thesymbology information 204 are typically 8 bits long. It is recognizedthat the code data 4 represented by the symbology information 204 in theOMRI 200 can be broken up into multiple blocks, such that each blockincludes a number (e.g. 255) of codewords in length.

Another example of an optical machine-readable (e.g. OMRI 200)representation of encoded information or data are DataGlyphs, which area new technology for encoding machine readable data onto paper documentsor other physical media. They encode information into a number of tiny,individual glyph elements. Each graphical (e.g. glyph) element canconsist of a small 45 degree diagonal line as short as 1/100th of aninch or less, depending on the resolution of the printing and scanningthat is used, for example. Each glyph element (as the symbologyinformation 204) represents a single binary 0 or 1 (as the decodedtextual information), depending on whether it slopes to the left orright. Sequences of these glyph elements (symbology information 204) canbe used to encode numeric, textual or other information (unencodedinformation).

As an example configuration of the dataglyph symbology and coding scheme209, the individual glyphs are grouped together on the page (ordisplayed electronically on a display), where they form unobtrusive,evenly textured gray areas, like half-toned pictures. One of the reasonsfor using diagonal glyph elements is because research has shown that thepatterns that they form when massed together are not visuallydistracting. DataGlyph technology allows ordinary business documents tocarry thousands of characters of information hidden in these unobtrusivegray patterns that can appear as backgrounds, shading patterns orconventional graphic design elements. Often, their presence will gocompletely unnoticed. (The entire Gettysburg Address will fit in aDataGlyph about the size of a small US postage stamp). DataGlyph areascan be printed on a document as part of its normal printing process ordisplayed on a screen as part of the normal image rendering process. Theinformation to be put in the DataGlyphs is encoded as a sequence ofindividual glyphs, and these can be printed either directly by theencoding software (for instance, by computer laser printer) or via aconventional printing process, such as offset. The glyphs are laid downon a finely spaced rectangular grid so that the area is evenly textured.In addition, each glyph area contains an embedded synchronizationlattice or “skeleton”—a repeating, fixed pattern of glyphs which marksthe boundaries of the glyph area and serves as a clocking track toimprove the reliability of reading. Before data is placed into thesynchronization frame, it's grouped into blocks of a few dozen bytes anderror correcting code is added to each block. The amount of errorcorrection to be used is chosen by the application, depending on theexpected quality of the print-scan cycle. Higher levels of errorcorrection increase the size of the glyph area needed for a given amountof data, but improve the reliability with which the data can be readback. This can be very important in environments where there's a highlevel of image noise (for example, fax) or where the documents aresubjected to rough handling. As a final step, the bytes of data arerandomly dispersed across the glyph area, so that if any part of theglyph area on the paper is severely damaged, the damage to anyindividual block of data will be slight, and thus easy for the errorcorrecting code to recover. Together, error correction and randomizationprovide very high levels of reliability, even when the glyph area isimpaired by ink marks, staples and other kinds of image damage.

In view of the above description, it is recognized that OMRI 200 can beembodied as barcodes, dataglyphs or other images that contain encodedsymbology information 204 that can be decoded into unencoded information(e.g. textual elements) using an appropriate coding scheme 209 thatprovides a mapping (e.g. rules) between the symbology information 204 tointo the unencoded information (e.g. the decoding process) and theunencoded information into the symbology information 204 (e.g. theencoding process). In any event, the following description, forsimplified example explanation purposes only, refers to OMRI 200 asbarcodes 200. However, it is recognized that in the below description,the term barcode 200 can be interchanged with the broader meaning ofOMRI 200, as desired.

Payment Application 13

Referring to FIG. 3, it is recognized that either of the paymentapplications 13, 14 can include a plurality of barcode 200 relatedprocessing functionality, a plurality of purchase transaction 5processing functionality and/or client confirmation 3 functionalityconfigured for network 11 communication with a transaction interface 15in a client-server relationship. For example, the application 13, 14 canbe configured as a thin client of the transaction interface 15, suchthat the application 13, 14 is configured to interact with a barcodeprocessing system of the transaction interface 15 via a series of webpages generated by the barcode processing system, sent via networkmessages and displayed on the user interface 104. Accordingly, theapplication 13, 14 would interact with a web browser (or other networkcommunication program) to send and receive the messages (correspondingto respective requests or associated responses for communications 3, 4,5) via the network 11 containing transaction 5 specific information,i.e. to display the web pages on the user interface 104 including outputdata used for the communications 3, 4, 5 and to coordinate the entry ofinput data on the user interface 104 and network transmission of theinput data for the communications 3, 4, 5.

Alternatively, the application 13, 14 can be configured as a thickclient of the transaction interface 15, such that the application 13, 14is provisioned with transaction and/or barcode processing functionalitysimilar to (or at least a portion of) that functionality of the barcodeprocessing system and/or barcode generation system of the transactioninterface 15, as further described below. It is recognized that thethick client version of the application 13, 14 could be configured toperform some of the transaction or barcode processing on behalf of orotherwise in substitution of any of the processing functionality of thebarcode processing system and/or the barcode generation systemimplemented by the transaction interface 15 during processing associatedwith the purchase transaction 5 and/or in providing a representativeOMRI 200 including the code data 4 upon request of the consumer 18 (e.g.represented in FIG. 3 as communication via network connection 1 of thecode data 4. It is also recognized that the thick client version of theapplication 13, 14 could be configured to communicate over the network11 via a series of web pages as generated or otherwise received by theof the transaction interface 15, sent as network messages between thecomputer devices 8, 12 and the transaction interface 15. It isrecognized that the payment application 13 could communicate with thetransaction interface 15 using network connection 1 and the merchantapplication 14 could communicate with the transaction interface 15 usingnetwork connection 0, as discussed above, thereby providing theadvantage of restricting sensitive merchant 16 information from theconsumer 18 (in use of network connection 0) and restricting sensitiveconsumer 18 information from the merchant 16 (in use of networkconnection 1).

Referring to FIGS. 3 and 4, the application can be configured as aclient application of the payment service platform 20, can be configuredfor generation (i.e. encoding) and presentment of the barcode 200 to themerchant 16 when operating as the payment application 13, and/or can beconfigured for receiving and incorporating the presented barcode 200(including the code data 4) and generation of a purchase transactionrequest 64 (including the purchase transaction 5) to the payment serviceplatform 20 when operating as the merchant application 14. The merchantapplication 14 is also configured to provide a graphical interface (onthe user interface 104—see FIG. 7), for example, to facilitate entry ofmerchant account information by the merchant 16 as well as entry of thefunds amount 203 requested (e.g. via a transaction generation module30). The payment application 13 is configured to provide a graphicalinterface, for example, to facilitate entry of consumer accountinformation (e.g. as code data 4, as PIN data in confirmationcommunication 3, etc.) by the consumer 18 as well as entry of aconfirmation message 3 that the funds amount 203 is correct. It isrecognized that the functionality of the application 13, 14, encounteredby a user during the purchase transaction 5, is dependent upon whichside the computer device 8, 12 is being utilized for, i.e. either themerchant 16 or the consumer 18.

Referring to FIG. 4, shown is an example configuration of theapplication 13, 14 that can include a network communications module 40for communicating (e.g. sending or receiving) request messages 42 withthe computer device 6 and for communicating (e.g. sending or receiving)response messages 44 with the computer device 6 over the communicationsnetwork 11. The network communications module 40 is also configured forsending a transaction request 64 (e.g. a request by the merchant 16containing the appropriate purchase transaction 5 (e.g. funds amount203, code data 4, as well as any product and merchant identificationinformation), to allow to the payment service platform 20 to coordinatethe actual funds transfer between accounts 70, 72) as well as receivingconfirmation messages 46 from the payment service platform 20(containing information indicating that the appropriate account 70, 72has been credited or debited as the case warrants).

The confirmation message(s) 46 received by the merchant application 14could contain details of the payment processing including that theappropriate account was (or will be) credited/debited by the fundsamount 203 of the purchase transaction 5, as well as any transfer data210 (see FIG. 5) identifying the purchase transaction 5 (e.g. transferID, merchant and/or consumer ID, description of the products, etc.) formerchant 16 accounting records. It is recognized that the paymentapplication 13 would could also receive confirmation message(s) 46containing details of the payment processing including that the consumeraccount was (or will be) debited by the funds amount 203 of the purchasetransaction 5, as well as any transfer data 210 identifying the purchasetransaction 5 (e.g. transfer ID, merchant and/or consumer ID,description of the products, etc.) for consumer 18 accounting records.

The network communications module 40 can also be configured to send andreceive the confirmation messages 46 over the communications network 11with respect to the payment service platform 20. Also included is adatabase 48 containing any optional product data 206 (e.g. productdescriptions, product availability, etc.), merchant data 208 (e.g.merchant bank account number, a unique merchant reference ID of themerchant assigned by the payment service platform 20 (e.g. via theregistration module 60—see FIG. 6), tax or merchant businessregistration details, and registration details 17 of the merchant),consumer data 211 (e.g. consumer bank account number, a unique consumerreference ID of the consumer assigned by the payment service platform 20(e.g. via the registration module 60—see FIG. 6), tax or consumerbusiness registration details, and registration details 17 of theconsumer) and network 11 address information of the payment serviceplatform 20. It is recognized that preferably the merchant application13 of the merchant 16 does not have access to sensitive consumer data211 (e.g. consumer PIN numbers and/or actual bank account numbers) andpreferably the payment application 13 of the consumer 18 does not haveaccess to sensitive merchant data 208 (e.g. merchant PIN numbers and/oractual bank account numbers).

The database 48 can also have customized barcode definitions of acustomized coding scheme 209 containing relationships (e.g. rules)between machine readable symbology and codewords used to encode (ordecode) code data 4 of the purchase transaction 5 information duringgeneration of the barcode 200 used to represent the sensitive accountinformation 61. For example, the customized coding scheme 209 can beused to encode (i.e. translate) text based code data 4 (see FIG. 5) ofthe purchase transaction 5 into symbology information 204, performedduring generation of the barcode 200 (e.g. by the computer device 8and/or the payment service platform 20). The customized coding scheme209 can also be used to decode (i.e. interpret) symbology information204 present in the barcode 200 into text based code data 4 duringprocessing of the barcode 200 (e.g. by the computer device 8 and/or thepayment service platform 20). It is recognized that the customizedcoding scheme 209 can be known to the payment service platform 20 andcan include customized codewords pertaining to specific code data 4 suchas but not limited to: registration details 17 of the consumer, consumerID, etc.

Referring again to FIG. 4, the payment application 13 also has atransaction generation module 30 used to collect the purchasetransaction 5 data (e.g. product data 206, merchant data 208, consumerdata 211, code data 4 and/or transfer data 210) associated with thefunds amount 203 selected/entered by the merchant 16 during initiationof the purchase transaction 5. It is recognized that optional productdata 206 and some of the consumer data 211 of the purchase transaction5, such as specific products ordered and quantity of each product, couldbe provided to the transaction generation module 30. Further, thetransaction generation module 30 would collect (or otherwise receive)the merchant data 208 for the purchase transaction 5 from the database48. The transaction generation module 30 also generates the purchasetransaction 5 data including the funds amount 203 (optionally includingapplicable taxes) that includes the total funds amount owed (forexample) by the consumer 18 and merchant identification information(associated with or otherwise embodying the merchant bank accountinformation) of the purchase transaction 5. For example, in terms of themerchant bank account information, this could be supplied as part of themerchant information included in the purchase transaction 5 data or thiscould be supplied as a merchant identification information (e.g.merchant ID) used by the payment service platform 20 to lookup theactual merchant bank account information known to the payment serviceplatform 20 (e.g. via the registration module 60—see FIG. 6) andtherefore abstracted from the consumer 18.

It is recognized that the network module 40 could also be configured toprovide to the user of the computer device 8 (via a presented graphicaluser interface on the user interface 104 of the computer device 8) theability to select or otherwise enter the desired consumer account 72(e.g. specifying a credit card number, a debit card number, or any otheraccount information for use in accepting/paying or otherwise confirmingthe funds amount 203) or for use during the generation of the code data4 and/or barcode 200 as specific to the desired consumer accountselected (i.e. the code data 4 and/or the barcode 200 is specific to theconsumer account selected by the consumer). The network module 40 couldalso provide, via the graphical user interface, the ability of theconsumer 18 to enter their PIN (or other password information specificto accessing their financial accounts directly) associated with thespecified consumer account, thereby indicating that the user of thecomputer device 8 at the time of generating the code data 4 and/orresultant barcode 200 has the authority to authorize the payment serviceplatform 20 (e.g. via the transfer processing module 65) to coordinatefunds transfer involving the specified consumer account. The PIN, orother password information specific to accessing the selected financialaccounts directly, can be considered as part of the code data 4 and/orbarcode 200 included in the purchase transaction 5 data (e.g. includedin the symbology information 204 if presented in the barcode 200) and/oras part of the confirmation messages 3, 46. For example, the PIN orother password information could not be the actual PIN or passwordinformation made available to the financial institutions of the accounts70, 72, rather could be a lookup identifier information used by thepayment service platform 20 (e.g. via the registration module 60) tolook up the actual PIN or password information 61 stored in theregistration details 17 of the consumer 18 using the reference PIN orpassword provided by the consumer 18 during generation of the code data4 encoded in the barcode 200 and/or provided as unencoded textualinformation to the merchant application 14.

This use of PIN or password information is advantageous, in addition toany passwords required to access the computer device 8 in general (e.g.device login) and/or login to the payment application 13 specifically,as the owner of the computer device 8 would not want any unauthorizedaccess to their financial accounts to occur. It is also envisioned thatthe entered PIN or password information could be done by the user inorder to login to the payment application 13 itself (i.e. access thefunctionality of the payment application 13 provisioned on the computerdevice 8). It is also recognized that the user of the computer device 8may wish to have separate PINs or passwords associated with each accountaccessible through the payment application 13 itself (e.g. selectable)and/or known to the payment service platform 20 (e.g. via theregistration module 60) via the registration details 17, in addition toa general login (including password) to the computer device 8 and/orpayment application 13 in general.

The payment application 13 can also have a barcode generation module 32,including an encoder 121, that is configured to use theavailable/collected code data 4 and the customized coding scheme 209 togenerate the barcode 200. It is recognized that the barcode 200 can begenerated by the barcode generation module 32 to contain the code data 4entered/selected by the consumer 18, used by the payment serviceplatform 20 to coordinate settlement of the financial transaction(associated with the purchase transaction 5 data) via the accountingprocessing system 2 in transferring funds from the specified account ofthe consumer 18 to the specified account of the merchant 16. In thisexample, it is envisioned that the consumer 18 is preregistered (i.e.has provided the registration details 17) with the transaction service20 and is provided with a consumer ID (e.g. via the registration module60) that is associated with the consumer's actual account information(and any other sensitive consumer information 61), both of which arestored in the lookup table 63 in a secure database 58 of the paymentservice platform 20 (thereby providing for the lookup by theregistration module 60).

It is also recognized that the barcode generation module 32 could beused to restrict access of the sensitive consumer account information 61by the merchant 16 by encoding the actual payment account numbers 72comprising textual information (and any associated passwords and/or PINdata) as symbology information 204 using the customized coding scheme209. In this embodiment, the consumer 18 would supply the actualfinancial account numbers and/or authorization information (e.g. PIN) tothe barcode generation module 32, which would encode the number(s)and/or authorization information in the symbology information 204 of thegenerated barcode 200, for subsequent presentment to the merchantapplication 14 and incorporation into the purchase transaction 5 datasupplied to the payment service platform 20 via the merchant application14. In this example, the payment service platform 20 would not need touse the lookup table 63 to access the financial account information 61of the consumer 18, rather would simply need to decode the symbologyinformation 204 of the barcode 200 in order to gain access to thefinancial account information 61 for subsequent transmission to theaccount processing system 2 for effecting the funds transfer of thefunds amount 203 from the account 72 (as identified and/or authorized bythe obtained financial account information 61) to the merchant account70.

Accordingly, it recognized that restricted access to the financialaccount information 61 can be provided in the split mobile paymentsystem 10 by: sending code data 4 as textual information representativeof the sensitive financial account information 61 (for subsequent use inthe lookup table); sending code data 4 as encoded symbology information204 in a generated barcode 200 that is representative of the sensitivefinancial account information 61 (for subsequent decoding by the paymentservice platform 20 and use in the lookup table); and/or sendingsensitive financial account information 61 as encoded symbologyinformation 204 in a generated barcode 200 that is the actual (i.e. notembodied as a lookup identifier) financial account information 61 (forsubsequent decoding and access by the payment service platform 20).

Encoding

One example of the customized coding interpretation scheme 209 forbarcodes is a modified UPC (Universal Product Code) to include code data4 and/or sensitive financial account number information 61 specificdata. Another example is a modified QR scheme, as further describedbelow. The numbers and/or letters (e.g. ASCII—American Standard Code forInformation Interchange) stored in the symbology information 204 of thebarcode 200 are unique identifiers representing the particular standardcode and custom code (representing purchase transaction 5 specific data)defined in the customized coding scheme 209 that, when read by thebarcode decoder 119 or encoder 121, can be used to look up additionalinformation about the item associated with the barcode 200.

Accordingly, the barcode generation module 32 takes the code data 4and/or the sensitive financial account number information 61 (i.e. asthe textual funds information) and uses the codes and associated rulesof the customized coding interpretation scheme 209 to convert a piece ofthe textual funds information (for example, a letter, word, phrase,etc.) of the code data 4 and/or the sensitive financial account numberinformation 61 into another form or representation (one sign intoanother sign), not necessarily of the same type, i.e. the symbologyinformation 204. In information processing performed by the barcodegeneration module 32, encoding is the process by which textual fundsinformation of the code data 4 and/or the sensitive financial accountnumber information 61 is converted into symbols (of the symbol format204 defined by the customized coding scheme 209) to becommunicated/presented. Decoding is the reverse process, convertingthese code symbols 204 back into textual funds informationunderstandable by a receiver. Therefore, the symbology information 204generated from the textual funds information of the code data 4 and/orthe sensitive financial account number information 61 is used by thebarcode generation module 32 to construct the barcode 200, according tothe customized coding scheme 209. This barcode 200 can be made availableto the network communications module 40 to be sent in the requestmessage 42 (delivered as an image file for example) to the computerdevice 12 or can be displayed on a browser screen of the user interface104 of the computer device 8. It is recognized that the barcode 200represents symbolically the textual data of the code data 4 and/or thesensitive financial account number information 61.

Referring again to FIG. 4, the payment application 13 also has a barcodepresentment module 33, used by the consumer 18 to transmit via requestmessages 42 and/or electronically display the image of the barcode 200to the merchant 16 on the display (of the user interface 104) of thecomputer device 8. Therefore, in addition to using the request messages42, the barcode presentment module 33 can be configured to provideinstructions to a printer for physically printing the barcode 200 and/orcan be configured to provide instructions to the electronic display fordisplaying the barcode 200. In either case, the barcode presentmentmodule 33 is configured to present the barcode 200 to the merchant 16for subsequent receipt or image capture (of the barcode 200) using thecomputer device 12 (e.g. mobile device).

Referring to FIG. 4, the payment application 14 also has a transactionrequest module 34 used to generate the account information of themerchant 16 as well as any other relevant responder data (e.g. productdata, barcode 200, code data 4), and to generate the purchasetransaction 5 and send in the transfer request 64 directed to thepayment service platform 20.

One embodiment, to provide for the sensitive portions of the symbologyinformation 204 to remain undecoded, is where the merchant application14 of the computer device 12 does not have access to the encryption keyused by the encoder 121 of the payment application 13 of the computerdevice 8. Further, in this example, it is recognized that in the eventwhere the payment service platform 20 does receive encoded symbologyinformation 204 in the transaction request 64, the payment serviceplatform 20 (e.g. via the registration module 60) would have access tothe consumer 18 encryption key via their respective registration details17 stored in the database 58.

In cryptography, the encryption key can be defined as a piece ofinformation (a parameter) that determines the functional output of acryptographic algorithm or cipher (i.e. as implemented by the encoder121 or decoder 119). Without the key, the algorithm of the encoder 121or decoder 119 would produce no useful result (i.e. the decodedsymbology information 204 would be meaningless). In encryption, the keyspecifies the particular transformation of plaintext into ciphertext, orvice versa during decryption. Keys can be used in cryptographicalgorithms, such as digital signature schemes and message authenticationcodes.

Further, the transaction request module 34 could also be configured toprovide to the user of the computer device 12 (via a presented graphicaluser interface on the user interface 104 of the computer device 12) theability to select or otherwise enter the desired merchant account (e.g.specifying a credit card number, a debit card number, or any otheraccount information for use in accepting the funds amount 203). Thetransaction request module 34 could also provide, via the graphical userinterface, the ability of the merchant 16 to enter their PIN (or otherpassword information specific to accessing their financial accountsdirectly) associated with the specified merchant account, therebyindicating that the user of the computer device 12 at the time ofgenerating the transaction request 64 has the authority to authorize thepayment service platform 20 (e.g. via the transaction processing module65) to coordinate funds transfer involving the specified merchantaccount. The PIN, or other password information specific to accessingthe selected financial accounts directly, can be considered as part ofthe merchant data included in transaction request 64 data 5, eitherdirectly or otherwise abstracted during generation of the transactionrequest 64. For example, the PIN or other password information would notbe the actual PIN or password information made available to thefinancial institutions of the accounts 70, 72, rather would be referenceinformation used by the payment service platform 20 (e.g. via theregistration module 60) to look up the actual PIN or passwordinformation stored in the registration details 17 of the merchant 16using the reference PIN or password information provided by the merchant16 during generation of the purchase transaction 5 and its submission inthe transaction request 64.

This use of PIN or password information is advantageous, in addition toany passwords required to access the computer device 12 in general (e.g.device login) and/or login to the merchant application 14 specifically,as the owner of the computer device 12 would not want any unauthorizedaccess to their financial accounts to occur. It is also envisioned thatthe entered PIN or password information could be done by the user inorder to login to the merchant application 14 itself (i.e. access thefunctionality of the merchant application 14 provisioned on the computerdevice 12). It is also recognized that the user of the computer device12 may wish to have separate PINs or passwords associated with eachaccount accessible through the merchant application 14 itself (e.g.selectable) and/or known to the payment service platform 20 (e.g. viathe registration module 60) via the registration details 17, in additionto a general login (including password) to the computer device 12 and/ormerchant application 14 in general.

Decoding

One example of the customized coding interpretation scheme 209 forbarcodes is modified UPC (Universal Product Code). The numbers and/orletters (e.g. ASCII—American Standard Code for Information Interchange)encoded in the barcode 200 are unique identifiers representing theparticular custom code defined in the customized coding scheme 209 that,when read by the barcode decoder 119, can be used to look up additionalinformation about the encoded items in the barcode 200. The decoder 119circuitry and/or software is used to recognize and/or to make sense ofthe symbology information 204 that make up barcode 200. The decoder 119can translates symbols 204 into corresponding digital output in atraditional data format (i.e. as textual funds information). In order todecode the information in barcode 200, for example for 1D barcodes, thewidths of the bars and spaces are recognized via edge detection andtheir widths measured.

Payment Service Platform 20 and Transaction Interface 15

Referring to FIG. 6, shown is an example configuration of the paymentservice platform 20 including the computer device 6 (e.g. a web server)hosting the transaction interface 15. The transaction interface 15 caninclude a network communications module 50 for receiving order requestmessages 52 (e.g. providing textual information and expecting a barcode200) from the computer device 12 and for sending account processingmessages 54 to the account processing system 2 over the communicationsnetwork 11.

The network communications module 50 can also be configured to send andreceive confirmation messages 46 to the computer devices 8, 12 (inresponse to the received request messages 64) over the communicationsnetwork 11 with respect to the computer devices 8, 12. Also included isa database 58 containing registration details 17 of merchant 16 and/orconsumer 18 as discussed above, and network 11 address information ofthe account processing system 2. The database 58 can also havecustomized barcode definitions of the customized coding scheme 209containing relationships (e.g. rules) between machine readable symbologyand codewords used to encode (or decode) fund information duringencoding and/or decoding of symbology information 204 of the barcode 200used in the purchase transaction 5. Further, the database 58 also hasstored the lookup table 63 containing the respective code data 4 mappedto respective sensitive financial account information 61 of the consumer18, such that any received code data 4 in the purchase transaction 5 isused by the transaction processing module 65 to access the sensitivefinancial account information 61 of the consumer 18 stored in the table63 using the received code data 4 as the lookup identifier.

For example, the customized coding scheme 209 can be used by the barcodegeneration module 62 to encode (i.e. translate) text based code data 4and/or sensitive financial account information 61 of the consumer 18into symbology information 204, performed during generation of thebarcode 200 for sending to the payment application 13. The customizedcoding scheme 209 can also be used to decode (i.e. interpret) symbologyinformation 204 present in the barcode 200 into text based code data 4and/or sensitive financial account information 61 of the consumer 18received in the purchase transaction 5 during processing of the barcode200. It is recognized that the customized coding scheme 209 is known tothe payment service platform 20 and can include customized codewordspertaining to specific code data 4 and/or sensitive financial accountinformation 61 of the consumer 18.

Referring again to FIG. 6, the transaction interface 15 also has aregistration module 60 used to collect the registration details 17during registration of the merchant 16 and/or the consumer 18. Furtherto that discussed above, it is recognized that the registration details17 can include PIN data and/or password data used to access thespecified account(s) 70, 72 through the financial institutions of theaccount processing system 2. For example, in terms of the merchant orconsumer bank account information, this could be supplied as part of thereference account information included in the transaction request 64,for example used by the registration module 60 to lookup the actualmerchant or consumer bank account information in the registrationdetails 17 known only to the payment service platform 20, and thereforeabstracted from the appropriate merchant or consumer.

The transaction interface 15 can also have the barcode generation module62 that is configured, by an encoder 121, to use the customized codingscheme 209 to generate the barcode 200, for subsequent delivery to thecomputer device 8. It is recognized that the barcode 200 is generated bythe barcode generation module 62 to contain code data 4 and/or sensitivefinancial account information 61 of the consumer 18 needed by theaccount transaction processing system 2 to settle the financialtransaction by transferring funds between specified accounts 70, 72.

Encoding

One example of the customized coding interpretation scheme 209 forbarcodes is a modified UPC (Universal Product Code) to include accountspecific data. Another example is a modified QR scheme, as furtherdescribed below. The numbers and/or letters (e.g. ASCII—AmericanStandard Code for Information Interchange) stored in the symbologyinformation 204 of the barcode 200 are unique identifiers representingthe particular standard code and custom code (representing accountspecific data) defined in the customized coding scheme 209 that, whenread by a barcode decoder 119, can be used to look up additionalinformation about the account item associated with the barcode 200.

Accordingly, the barcode generation module 62 takes the code data 4and/or sensitive financial account information 61 of the consumer 18 anduses the codes and associated rules of the customized codinginterpretation scheme 209 to convert a piece of the textual accountinformation (for example, a letter, word, phrase, etc.) into anotherform or representation (one sign into another sign), not necessarily ofthe same type, i.e. the symbology information 204. In informationprocessing performed by the barcode generation module 62, encoding isthe process by which textual account information is converted intosymbols (of the symbol format 204 defined by the customized codingscheme 209) to be communicated. Decoding is the reverse process,converting these code symbols 204 back into textual account informationunderstandable by a receiver. Therefore, the symbology information 204generated from the textual account information is used by the barcodegeneration module 62 to construct the barcode 200, according to thecustomized coding scheme 209. This barcode 200 is made available to thenetwork communications module 50 to be sent in the message 54 (forexample) to the computer device 8 (e.g. displayed on a browser screen ofthe user interface 104 of the computer device 8 or otherwise deliveredas an image file in the network message 54, etc.). It is recognized thatthe barcode 200 represents symbolically the textual account data.

Referring to FIG. 6, the transaction interface 15 can also have adecoder module 66, including the decoder 119, used to decode thereceived barcode 200 in the case where the transaction request 64 dataincludes symbology information 204. For example, the decoder 119 couldbe used to decode account information of the consumer 18 (pertaining tothe selected mode of payment/credit of the consumer 18 and optionallyincluding the PIN or password data of the consumer account) as well asany other relevant consumer data from the symbology 204, for exampleusing the respective encryption key stored in the registration details17 of the consumer 18). One embodiment, to provide for the sensitiveportions of the symbology information 204 to be decoded, is where thedecoder 119 of the computer device 6 has access to the encryption key(via the registration details 17) used by the encoder 121 used by thepayment application 13 of the computer device 8. It is also envisionedthat the decoder 119 can have access to the encryption key used by thepayment application 13 of the computer device 8. Therefore, in the eventwhere the payment service platform 20 does receive encoded symbologyinformation 204 in the transaction request 64, the payment serviceplatform 20 would have access to the consumer encryption key via theirrespective registration details 17 stored in the database 58.

One example of the customized coding interpretation scheme 209 forbarcodes is modified UPC (Universal Product Code). The numbers and/orletters (e.g. ASCII—American Standard Code for Information Interchange)encoded in the barcode 200 are unique identifiers representing theparticular custom code defined in the customized coding scheme 209 that,when read by the barcode decoder 119, can be used to look up additionalinformation about the account information item associated with thebarcode 200. The decoder 119 circuitry and/or software is used torecognize and/or to make sense of the symbology information 204 thatmake up barcode 200. The decoder 119 can translates symbols 204 intocorresponding digital output in a traditional data format (i.e. astextual account information). In order to decode the information inbarcode 200, for example for 1D barcodes, the widths of the bars andspaces are recognized via edge detection and their widths measured.

Referring again to FIG. 6, once all of the textual account informationis received by the transaction interface 15 or otherwise decoded, atransfer processing module 65 communicates using processing messages 56with the account processing system 2. It is recognized that theprocessing messages 56 could include decoded account data (e.g. textualaccount information) obtained directly from the symbology information204 of the barcode 200, and/or as received from the lookup process usingdecoded code data 4 in the table 63.

Further, the transfer processing module 65 could be configured toconfirm whether the received PIN or password information of the merchantand/or the consumer matches the corresponding PIN or passwordinformation stored in their respective registration details 17 that isassociated with their respective account (e.g. credit card number, adebit card number, or any other account information for use inaccepting/paying the funds amount 203). In the event that the receivedPIN or password information (for the merchant and/or the consumer)matches the corresponding PIN or password information stored in theirrespective registration details 17, the transfer processing module 65has confirmed that the respective merchant 16 and/or the respectiveconsumer 18 had the authority to authorize the payment service platform20 to coordinate funds transfer involving the specified financialaccount(s). In the event that the received PIN or password information(for the merchant and/or the consumer) does not match the correspondingPIN or password information stored in their respective registrationdetails 17, the transfer processing module 65 could deny the transactionrequest 64 and send notice of the denial back to the computer devices 8,12 via the respective transaction confirmation messages 46. For example,if both matches fail, then both of the computer devices 8, 12 would benotified of the denial. Otherwise if only one of matches failed, thenthe respective one of the computer devices 8, 12 would be notified ofthe denial.

In any event, the transfer processing module 65 is also configured toreceive confirmation message(s) 56 from the account processing system 2,such that confirmation message(s) 56 include a confirmation that thefunds amount has either been transferred between accounts 70, 72 ordeclined. The confirmation message(s) 56 sent by the payment serviceplatform 20 can include instructions to the respective financialinstitutions (not shown), for example, associated with the customer andmerchant account information to debit the appropriate account 70, 72 andcredit the appropriate account 70, 72 by the funds amount 203 along withthe required account data and (optional) PIN or password data. Theconfirmation message(s) 56 received by the transaction interface 15 fromthe account processing system 2 could contain details of the paymentprocessing including that the accounts were (or will be) credited by theamount, as well as any transfer data 210 (e.g. transfer ID) foraccounting records.

In is recognized in the above embodiments, that in terms of the accountinformation, this could be supplied as specifically the account numberor this could be supplied as identification information (e.g. accountID) used by the payment service platform 20 to lookup the actual bankaccount information known to the payment service platform 20 (via therespective registration details 17) and therefore the account numberwould be abstracted from the general communications over the network 11.

Computer Device 8, 12

Referring to FIG. 7, each computer device 8, 12 can be awireless-enabled (e.g. WiFi, WAN, etc.) personal data assistant, oremail-enabled wireless telephone, or a desktop computer terminal. Inaddition, the wireless communications are not limited to onlyfacilitating transmission of text data (e.g. encrypted) and cantherefore be used to transmit image data, audio data or multimedia data,for example, as desired.

As shown in FIG. 7, the computer device 8, 12 comprises a communicationnetwork interface 102, a user interface 104, and a data processingsystem 106 in communication with the network interface 102 and the userinterface 104. The network interface 102 can include one or moreantennas for wireless communication over the communications network 11.Preferably, the user interface 104 comprises a data entry device (suchas keyboard, microphone or writing tablet), and a display device (suchas an LCD display). The display screen of the user interface 104 can beused to visually present a graphical user interface (GUI) of theapplication 13, 14 to the user, including results of the barcode 200image capture process and processing. The display screen can employ atouch screen display, in which case the user can manipulate (i.e. enterand/or modify/delete) account and purchase transaction 5 information(e.g. product data 206, requestor data 208, responder data 211 and/ortransfer data 210) in order to generate the transaction request 64.

The data processing system 106 includes a central processing unit (CPU)108, otherwise referred to as a computer processor, and a non-volatilememory storage device (e.g. DISC) 48 (such as a magnetic disc memory orelectronic memory) and a read/write memory (RAM) 112 both incommunication with the CPU 108. The memory 48 includes data which, whenloaded into the RAM, comprise processor instructions for the CPU 108which define memory objects for allowing the computer devices 8, 12 tocommunicate with one another and the payment service platform 20 (foraccessing the transaction interface 15) and the account processingsystem 2 (e.g. one or more processing servers) over the communicationsnetwork 11. The mobile device 8, 12, and the processor instructions forthe CPU 108 will be discussed in greater detail below.

The CPU 108 is configured for execution of the application 13, 14 forfacilitating communication with the payment service platform 20, thecomputer device 8, 12 and the computer device 6. For example, it isrecognised that the application 13, 14 is used to coordinate, asimplemented by the CPU 108, the generation, receipt, and processing ofthe barcode 200 and the transaction messages 64. For example, thepayment application 13 can operate the imager 118 and theencoder/decoder 119, 121.

The CPU 108 facilitates performance of the computer device 8, 12configured for the intended task (e.g. of the respective module(s) ofthe application 13, 14) through operation of the network interface 102,the user interface 104 and other application programs/hardware (e.g. webbrowser made available to the application 13, 14) of the computer device8, 12 by executing task related instructions. These task relatedinstructions can be provided by an operating system, and/or softwareapplications located in memory, and/or by operability that is configuredinto the electronic/digital circuitry of the processor(s) 108 designedto perform the specific task(s), including operation of the modules 30,32, 33, 34, 40. Further, it is recognized that the device infrastructure106 can include a computer readable storage medium 48 coupled to theprocessor 108 for providing instructions to the processor 108 and/or toload/update the instructions. The computer readable medium 48 caninclude hardware and/or software such as, by way of example only, memorycards such as flash memory or other solid-state memory.

Further, it is recognized that the computer device 8, 12 can include theexecutable applications comprising code or machine readable instructionsfor implementing predetermined functions/operations including those ofan operating system, the imager 118, the decoder 119, the encoder 121and the application 13, 14 for example. The processor 108 as used hereinis a configured device and/or set of machine-readable instructions forperforming operations as described by example above, including thoseoperations as performed by any or all of the imager 118, the decoder119, the encoder 121 and the application 13, 14. As used herein, theprocessor 108 may comprise any one or combination of, hardware,firmware, and/or software. The processor 108 acts upon information bymanipulating, analyzing, modifying, converting or transmittinginformation for use by an executable procedure or an information device,and/or by routing the information with respect to an output device. Theprocessor 108 may use or comprise the capabilities of a controller ormicroprocessor, for example.

The data processing system 106 can include the imager 118 (e.g. a cameraincluding an image sensor—e.g. CCD or CMOS sensor) suitable forcapturing images of the barcode 200 displayed or otherwise presented tothe merchant 16 within range of the imager 118. The application 13, 14is configured to control the operation of the imager 118 to capture theimage of the barcode 200. The storage 48 can also contain the customizedcoding interpretation scheme 209 for use in decoding/encoding thebarcode 200.

Transaction Service Device 6

Referring to FIG. 8, the device 6 can be a wireless-enabled (e.g. WiFi,WAN, etc.) personal data assistant, or email-enabled wireless telephone,for example a tablet. In addition, the wireless communications are notlimited to only facilitating transmission of text data (e.g. encrypted)and can therefore be used to transmit image data, audio data ormultimedia data, for example, as desired. Preferably, the device 6 is anetwork server.

As shown in FIG. 8, the device 6 can comprise a communication networkinterface 102, a user interface 104, and a data processing system 106 incommunication with the network interface 102 and the user interface 104.The network interface 102 can include one or more antennas for wirelesscommunication over the communications network 11. The user interface 104can comprise a data entry device (such as keyboard, microphone orwriting tablet), and a display device (such as an LCD display).

The data processing system 106 includes a central processing unit (CPU)108, otherwise referred to as a computer processor, and a non-volatileor volatile memory storage device (e.g. DISC) 58 (such as a magneticdisc memory or electronic memory) and a read/write memory (RAM) 112 bothin communication with the CPU 108. The memory 58 includes data which,when loaded into the RAM, comprise processor instructions for the CPU108 which define memory objects for allowing the device 6 to communicatewith the computer devices 8, 12 and the account processing system 2(e.g. one or more processing servers) over the communications network11. The instructions can be used to provide or otherwise host thetransaction interface 15 as a website running on the computer device 6and accessed via the network 11.

The CPU 108 is configured for execution of the transaction interface 15for facilitating communication with the account processing system 14 andthe computer devices 8, 12. For example, it is recognised that thetransaction interface 15 is used to coordinate, as implemented by theCPU 108, the generation, receipt, and processing of the textual accountinformation and the symbology information 204 of the barcode 200, aswell as coordinating the settlement of funds transfer of the fundsamount 203 between the specified accounts 70, 72.

The CPU 108 facilitates performance of the device 6 configured for theintended task (e.g. of the respective module(s) of the transactioninterface 15) through operation of the network interface 102, the userinterface 104 and other application programs/hardware (e.g. web servicemade available through the transaction interface 15) of the device 6 byexecuting task related instructions. These task related instructions canbe provided by an operating system, and/or software applications locatedin memory, and/or by operability that is configured into theelectronic/digital circuitry of the processor(s) 108 designed to performthe specific task(s). Further, it is recognized that the deviceinfrastructure 106 can include the computer readable storage medium 58coupled to the processor 108 for providing instructions to the processor108 and/or to load/update the instructions. The computer readable medium58 can include hardware and/or software such as, by way of example only,memory cards such as flash memory or other solid-state memory. Thestorage 58 can also contain the customized coding interpretation scheme209 for use in encoding and/or decoding the barcode 200.

Further, it is recognized that the device 6 can include the executableapplications comprising code or machine readable instructions forimplementing predetermined functions/operations including those of anoperating system and the modules 50, 60, 62, 63, 65, 66 for example. Theprocessor 108 as used herein is a configured device and/or set ofmachine-readable instructions for performing operations as described byexample above, including those operations as performed by any or all ofthe modules 50, 60, 62, 63, 65, 66. As used herein, the processor 108may comprise any one or combination of, hardware, firmware, and/orsoftware. The processor 108 acts upon information by manipulating,analyzing, modifying, converting or transmitting information for use byan executable procedure or an information device, and/or by routing theinformation with respect to an output device. The processor 108 may useor comprise the capabilities of a controller or microprocessor, forexample.

Example Operation of the System 10

The disclosed split mobile payment system 10 provides for the Consumer18 to use his/her Mobile Device 8 to facilitate a financial transactionat a merchant Terminal 12 through the use of the payment application 13running on such Mobile Device 8 that allows the Consumer 18 to provide aPayment Account Identifier (e.g. code data 4 and/or a generated barcode200 containing encoded sensitive financial account information 61 of theconsumer 18) to a Payment Platform 20 via the Terminal 12. For thepurposes of providing a Consumer's Payment Account Identifier, it iscontemplated that several Mobile Device technologies may be utilized,including Image Technology and Transmitting Technology. Where ImageTechnology is used, the Payment Account Identifier can be presented(e.g., in the form of a graphical image, such as a I-D barcode, 2-Dbarcode or hologram) on the Consumer's Mobile Device 8 for scanning viathe Terminal 12, whereas where Transmitting Technology is used, thePayment Account Identifier or the Payment Account IdentifyingInformation is electronically communicated (e.g., via NFC, Bluetooth,Infrared or other similar short-range communication technology) from theConsumer's Mobile Device 8 to the Payment Platform 20 via the Terminal12. The disclosed split mobile payment system 10 allows the Consumer 18to pay for his/her purchase by charging the purchase amounts to one orseveral of his/her Payment Accounts 72 accessible via the PaymentPlatform 20.

The disclosed system utilizes a “Split Transaction Process” that dividesthe sensitive parts of an electronic POS payment process between theTerminal 12, the Consumer's Mobile Device 8 and the Payment Platform 20.Specifically, the disclosed system 10 provides that the steps of a POSpayment process which involve sensitive Payment Account Information 61of the Consumer 18 (including for example Payment Account accountnumber(s), Payment Account balances, Payment Account passwords and/orand Payment Account PINs) are processed between the Consumer's MobileDevice 8 and the Payment Platform 20, thereby avoiding the Consumer 18having to expose any confidential credit card, debit card or financialinformation 61 to the merchant 16. Nor does it need the Consumer 18 toenter any credit card or debit card PINs into the merchant's Terminal12. All sensitive Payment Accounts and Payment Account Information 61 ishoused on the Payment Platform 20 and therefore access to such sensitiveinformation 61 is restricted from the merchant 16 and the merchantcomputer systems 12.

The steps involved in an exemplary payment transaction 5 utilizing theSplit Mobile Payment System 10 is described below, with reference toFIGS. 3 and 9.

1. After having selected the goods and/or services he/she wishes topurchase, the Consumer 18 proceeds to the checkout area in themerchant's 16 store.

2. The cashier may ring in the items and calculate the total amount theConsumer 18 must pay (per-item cost plus taxes, typically).

3. At this point the Consumer 18 may login to his/her Mobile Device 140and start the MPA 145 (e.g. payment application 13) on the Mobile Device140.

4. Before proceeding, the MPA 145 may authenticate the Consumer 18through a standard password prompt or similar method.

5. The MPA 145 may confirm the authentication by communicating with thePayment Platform 155 (e.g. payment service platform 20) back-end serversvia the Internet 150. (Step A).

6. Upon successful authentication, the MPA 145 can display theConsumer's 18 unique identifying barcode 160 (or other Image Technology)(or optionally the code data 4) on the screen of the Mobile Device 140.The barcode 160 (or optionally the code data 4) will contain theConsumer's Payment Account Identifying Information. (Step B).

7. The Consumer 18 can present the barcode 160 on the screen of his/herMobile Device 140 to be scanned by an image scanner 118 at the cashierof the PPA 165 (e.g. merchant application 14). It is contemplated thatthe Terminal 170 can incorporate image scanning functionality so as tofunction as a suitable image scanner, or the image scanner may be aseparate device in communication with the PPA 165.

8. After successfully reading the barcode 160 or receiving the PaymentAccount Identifying Information (e.g. the code data 4), the PPA 165 caninitiate a purchase transaction request 5 to the Payment Platform server155 (e.g. device 6) via the Internet 150 using the network connection 0(or optionally through a dedicated connection). This purchasetransaction request 5 may contain the Payment Account IdentifyingInformation received from the Mobile Device 140, information about thepurchase (e.g. transaction amount, items purchased, etc.) and/orinformation about the merchant (merchant identifier, merchantauthentication key). (Step C).

9. The Payment Platform 155 can authenticate the merchant transactionrequest and notify (e.g. using the network connection 1 as a response tothe purchase transaction request 5) the MPA 145 of the pendingtransaction via the Internet 160. The notification request may includethe transaction information from the merchant 16 (e.g. transactionamount, merchant name and items being purchased). (Step D). Optionally,the Payment Platform 155 can also send a photo of the Consumer 18 to thePPA.

10. The MPA 145 may then display on the Mobile Device 140, thetransaction amount, the items being purchased (optional), the merchant16 name and provide the Consumer 18 with the option of how he/she wishesto pay. The options presented will depend on options available to theparticular Consumer 18. Typical payment methods include but are notlimited to: E-wallet, coupon, gift-card, debit and credit card asselectable that pertain to the sensitive financial account information61 of the consumer 18 known to the payment processor 155. Additionallimitations on the options may be imposed based on funds available foreach of the configured methods, currency, transaction amount or otherparameters. In the case of gift-cards or coupons, the funds available tothe Consumer 18 can be altered based on pre-defined properties of thecoupon or gift-card. For example, a gift-card for Merchant X entered inthe Consumer's account 72 on the Payment Platform 155 may only increasethe funds available to the Consumer 18 when a purchase is being made atMerchant X.

11. The Consumer 18 can select their preferred Payment Account 72 viathe MPA 145.

12. The MPA 145 can then return the Consumer's 18 selected option to thePayment Platform 155. (Step E).

13. In the event that the selected Payment Account 72 requires a PINverification, the MPA 145 can prompt the Consumer 18 to enter the PINnumber on the mobile device 140.

14. The MPA can send the entered PIN number to the Payment Platform 155for authentication.

15. Upon successful authentication of the PIN, the Payment Platform 155may then perform the requested financial transactions to charge theamount of the transaction to the Consumer's Payment Account 72 andcredit that amount to the merchant 16, e.g. via the account processingsystem 2.

16. Upon completion of the transaction by the Payment Platform 155, boththe merchant 16 and the MPA 145 may be updated with the transactioninformation (Step F), including but not limited to the following:

Date and time

Merchant name

Transaction id

Transaction amount

Transaction status (approved, declined)

Any other identifying information required by the merchant and governingPOS standards.

17. The merchant 16 can be notified that the transaction 5 has beencompleted by the Payment Platform 155 responding to the initialtransaction initiation request 5 (step 8) with the details listed above,for example using the network connection 0 as either a synchronous orasynchronous message in response to the original purchase transaction 5request.

18. The MPA 145 can be notified by responding to the confirmationrequest (step 12) with the same details as are sent to the merchant 16,for example using the network connection 1 as either a synchronous orasynchronous message in response to the original confirmation request ofstep D above.

19. The PPA Terminal 170 can print out a receipt confirming completionof the transaction for the Consumer's 18 reference.

20. The MPA 145 may also display the results of the transaction on theMobile Device's 8 screen.

21. A confirmation e-mail can be sent to the Consumer's 18 registerede-mail address (e.g. of the device 8).

22. In an embodiment, the transaction 5 is now completed and theConsumer 18 has paid for the purchase.

In an alternative embodiment, where Transmitting Technology is usedinstead of Image Technology, steps 6 and 7 above could simply bereplaced by the following step:

6. Upon successful authentication, the MPA 145 may have the MobileDevice 140 transmit the Consumer's Payment Account Identifier or PaymentAccount Identifying Information using the Transmitting Technology to thePPA via the PPA Terminal. (Step B).

As will be apparent to one skilled in the art, the disclosed splitmobile payment system 10 provides (or can be configured to provide) anumber of notable advantages/features over the prior art, including butnot limited to the following:

1. It can inhibit credit card/debit card PIN numbers from being stolenby unscrupulous merchants or merchant employees, since PIN numbers areonly required to be entered into the Consumer's Mobile Device and not amerchant POS terminal.

2. It can inhibit credit card information from being stolen or misusedby merchants or merchant employees, since a payment card isn't requiredto be physically presented to the merchant or to be swiped by themerchant.

3. In the case of an ATM implementation where bank ATM machinefunctionality is transferred to the MPA, it can inhibit bank card PINnumbers from being stolen, thereby making it difficult to clone aConsumer's bank card.

4. It optionally provides Account Holder identification, by providingthe merchant with “out-of-band” photo ID of the Account Holder forverification purposes. The Account Holder's photo is delivered to themerchant from the Payment Platform, rather than being located on thebarcode or Mobile Device, where a thief could potentially change it tohis/her own photo.

5. It can inhibit fraud by needing the Consumer to have his/her MobileDevice in his/her possession and to know the PIN number. This inhibits athief from cloning the barcode and trying to use it on another MobileDevice.

6. It can provide the Consumer with real-time notification of accountmisuse. Since all requests for payment are pushed to the ConsumersMobile Device, if a consumer's barcode was cloned and someone else triedto use it on another Mobile Device, the request for payment confirmationwould be sent to the Consumer's Mobile Device, thus allowing them tostop and report the transaction.

7. It can free the Consumer from having to carry payment cards and/or acheque book.

8. It can reduce the check out time at a POS/cashier.

9. It can allow for the real-time digital issuing of gift certificatesand coupons.

10. It can allow a Consumer to buy someone else a beer or any othergoods or service as per the process outlined in step 9 remotely.

11. It can allow for a funds transfer to be sent from one person toanother for use at a specific location. Since all merchants have aunique Merchant ID, a person-to-person funds transfer can be initiatedby the MPA that is tagged to a Merchant ID, meaning the funds can onlybe spent at that specific merchant.

12. The split mobile payment system 10 can be adapted to allow a parentto give young children a copy of his/her barcode 200 and/or code data 4that they can use (e.g., a paper copy or a copy on a piece of clothing,etc.). All transaction requests would go back to the parent's MobileDevice 8 for authorization, such that the processing of the purchasetransaction 5 would be between the devices 6, 8 and 6, 12 as discussedabove. In this case, the device or person (e.g. child) providing thecode data 4 and/or barcode 200 to the merchant application 14 is otherthan the owner of the device 8 (e.g. the parent of the child).

Further, referring to FIG. 3, the split transaction system 10coordinates processing of the purchase transaction 5 between themerchant 16 and the consumer 18 over the communications network 11 by:the payment service platform 20 (via the transaction interface 15)receiving the purchase transaction 5 from the merchant 16 includingmerchant identification information (e.g. product data, funds amountdata, and/or merchant ID data including financial account information,etc.) and consumer identification information (e.g. code data 4 and/orsensitive financial account information encoded in the barcode 200),such that the consumer identification information includes consumerfinancial account information (e.g. code data 4 and/or sensitivefinancial account information 61 encoded in the barcode 200) that isunusable to directly access the corresponding financial account 72 ofthe consumer 18; contacting the consumer 18 to notify the consumer 18 ofthe received purchase transaction 5 and to request confirmationinformation (such as confirmation of the funds amount associated withthe purchase transaction 5, selection of a financial account 72 type,and/or PIN or password data) from the consumer 18; receiving theconfirmation information from the consumer 18 and generating acorresponding funds transfer request using a funds amount 203 associatedwith the merchant identification information and a financial accountnumber of the financial account 72 of the consumer 18; and sending thefunds transfer request to the account processing system 2 for subsequentsettlement of the funds amount 203 with the financial account 72 of theconsumer 18. It is recognized that the financial account 72 number (e.g.sensitive data 61) is obtained either directly from the barcode 200 oncedecoded or using the code data 4 in the lookup table 63

Further, referring to FIG. 3, the split transaction system 10coordinates processing of the purchase transaction 5 between themerchant 16 and the consumer 18 over the communications network 11 by:providing consumer identification information (e.g. code data 4 and/orsensitive financial account information 61 encoded in the barcode 200)to the merchant 16, such the consumer identification includes consumerfinancial account information that is unusable to directly access thecorresponding financial account 72 of the consumer 18; receiving by thepayment application 13 a notification from the payment service platform20 of the purchase transaction 5 including merchant identificationinformation and a request to provide confirmation information from theconsumer 18 pertaining to the purchase transaction 5; sending by thepayment application 13 the confirmation information to the paymentservice platform 20 including confirmation of the funds amount 203associated with the merchant identification information; and receivingnotification from the payment service platform 20 by the paymentapplication 13 of subsequent settlement of the funds amount 203 with thefinancial account 72 number pertaining to the financial account 72 ofthe consumer 18.

The embodiments described herein are illustrative of the presentdisclosure and are not intended to limit the scope of the disclosure tothe particular embodiments described. It will be appreciated by thoseskilled in the art that various changes can be made therein withoutdeparting from the spirit of the disclosure.

We claim:
 1. (canceled)
 2. A split transaction server coordinatingprocessing of a purchase transaction between a merchant and a consumerover a network with interaction involving the server, a merchant device,and a consumer device, the split transaction server comprising: acomputer processor coupled to a memory, wherein the computer processoris programmed to coordinate processing of the purchase transaction by:receiving by the computer processor from the consumer device over thenetwork the purchase transaction via a network communications moduleincluding merchant information and consumer information, such that themerchant information is encoded information unusable by the consumer todirectly access through a payment processing system a financial accountof the merchant; decoding by the computer processor the encodedinformation and retrieving, via a lookup from a merchant profile,merchant financial account information using the decoded information todirectly access through the payment processing system the financialaccount of the merchant; generating by the computer processor by thenetwork communications module a configured notification that includes arequest for entry of confirmation information from the consumer devicefor the purchase transaction; contacting directly by the computerprocessor a consumer program application of the consumer device bysending the configured notification for display on a user interface ofthe consumer device requesting entry of the confirmation information forthe purchase transaction from the user interface based on the configurednotification; receiving by the computer processor the confirmationinformation from the consumer device and generating a correspondingfunds transfer request between the merchant financial account and afinancial account associated with the consumer using a funds amount;sending the funds transfer request by the computer processor to thepayment processing system for subsequent settlement of the funds amountwith the financial account of the consumer and the financial account ofthe merchant; and sending by the computer processor the approval or thedenial of the purchase transaction to at least one of the consumerdevice or the merchant device.
 3. The server of claim 2, wherein theencoded merchant financial account information is an optical machinereadable image containing an encoded version of a financial accountnumber encoded in symbology information of the optical machine readableimage.
 4. The server of claim 3, wherein the computer processor isfurther programmed to: decode the symbology information into unencodedinformation using a coding scheme of the optical machine readable imageas a barcode in order to extract the financial account of the merchant.5. The server of claim 2, wherein the purchase transaction is receivedfrom a first network connection with the consumer device and theapproval or denial is sent using a second network connection with themerchant device, such that the first network connection and the secondnetwork connection are associated with different network devices.
 6. Theserver of claim 2, wherein the computer processor is further programmedto: receive a PIN from the consumer device in response to theconfirmation information request.
 7. The server of claim 2 furthercomprising receiving by the computer processor a selected financialaccount type from the consumer device in response to the confirmationinformation request, the selected financial account type one of aplurality of account types stored in a consumer profile accessible bythe split transaction server.
 8. The split transaction server of claim 2further comprising: using by the computer processor the consumerinformation to obtain an image of the consumer from a consumer profileand sending the image to the merchant device over the network in orderto verify an identity of the consumer with the merchant.
 9. The splittransaction server of claim 2 further comprising identifying the fundsamount of the purchase transaction in the encoded information oncedecoded.
 10. A method for coordinating processing of a purchasetransaction between a merchant and a consumer over a network withinteraction involving a split transaction server, a merchant device anda consumer device, the split transaction method implementing storedinstructions by a computer processor to perform the following steps of:receiving by the computer processor from the consumer device over thenetwork the purchase transaction via a network communications moduleincluding merchant information and consumer information, such that themerchant information is encoded information unusable by the consumer todirectly access through a payment processing system a financial accountof the merchant; decoding by the computer processor the encodedinformation and retrieving, via a lookup from a merchant profile,merchant financial account information using the decoded information todirectly access through the payment processing system the financialaccount of the merchant; generating by the computer processor by thenetwork communications module a configured notification that includes arequest for entry of confirmation information from the consumer devicefor the purchase transaction; contacting directly by the computerprocessor a consumer program application of the consumer device bysending the configured notification for display on a user interface ofthe consumer device requesting entry of the confirmation information forthe purchase transaction from the user interface based on the configurednotification; receiving by the computer processor the confirmationinformation from the consumer device and generating a correspondingfunds transfer request between the merchant financial account and thefinancial account of the consumer using a funds amount; sending thefunds transfer request by the computer processor to the paymentprocessing system for subsequent settlement of the funds amount with thefinancial account of the consumer and the financial account of themerchant; and sending by the computer processor the approval or thedenial of the purchase transaction to at least one of the consumerdevice or the merchant device.
 11. The method of claim 10, wherein theencoded merchant financial account information is an optical machinereadable image containing an encoded version of a financial accountnumber encoded in symbology information of the optical machine readableimage.
 12. The method of claim 11, wherein the computer processor isfurther programmed to: decode the symbology information into unencodedinformation using a coding scheme of the optical machine readable imageas a barcode in order to extract the financial account of the merchant.13. The method of claim 10, wherein the purchase transaction is receivedfrom a first network connection with the consumer device and theapproval or denial is sent using a second network connection with themerchant device, such that the first network connection and the secondnetwork connection are associated with different network devices. 14.The method of claim 10, wherein the computer processor is furtherprogrammed to: receive a PIN from the consumer device in response to theconfirmation information request.
 15. The method of claim 10 furthercomprising receiving by the computer processor a selected financialaccount type from the consumer device in response to the confirmationinformation request, the selected financial account type one of aplurality of account types stored in a consumer profile accessible bythe split transaction server.
 16. A split transaction servercoordinating processing of a purchase transaction between a merchant anda consumer over a network with interaction involving the server, amerchant device, and a consumer device, the split transaction servercomprising: a computer processor coupled to a memory, wherein thecomputer processor is programmed to coordinate processing of thepurchase transaction by: receiving by the computer processor from theconsumer device over the network the purchase transaction via a networkcommunications module including merchant information and consumerinformation, such that the merchant information is encoded informationunusable by the consumer to directly access through a payment processingsystem a financial account of the merchant; decoding by the computerprocessor the encoded information and retrieving, via a lookup from aconsumer profile, consumer financial account information using thedecoded information to directly access through the payment processingsystem the financial account of the consumer; generating by the computerprocessor by the network communications module a configured notificationthat includes the consumer information with a request for entry ofconfirmation information of financial account type from the consumerdevice for the purchase transaction; contacting directly by the computerprocessor a consumer program application of the consumer device bysending the configured notification for display on a user interface ofthe consumer device requesting entry of the confirmation information forthe purchase transaction from the user interface based on the configurednotification, the confirmation information including a request for thefinancial account type from a plurality of financial account typesstored in a consumer profile accessible by the split transaction server;receiving by the computer processor the confirmation information fromthe consumer device including the financial account type and generatinga corresponding funds transfer request between the merchant financialaccount and the financial account of the consumer pertaining to thefinancial account type using a funds amount; sending the funds transferrequest by the computer processor to the payment processing system forsubsequent settlement of the funds amount with the financial account ofthe consumer and the financial account of the merchant; and sending bythe computer processor the approval or the denial of the purchasetransaction to at least one of the consumer device or the merchantdevice.
 17. The split transaction server of claim 16, wherein theplurality of financial account types is limited based on availabilitywith the merchant.
 18. The split transaction server of claim 17, whereinthe confirmation information includes password information for thefinancial account type.
 19. The split transaction server of claim 17,wherein the funds amount is obtained from the encoded information. 20.The split transaction server of claim 16 further comprising: using bythe computer processor the consumer information to obtain an image ofthe consumer from a consumer profile and sending the image to themerchant device over the network in order to verify an identity of theconsumer with the merchant.